谈单进程（单线程）与单进程（多线程）程序设计

本文单进程指单进程（单线程）模式；单线程也指单进程单线程；多线程指单进程（多线程模式），下同。

 

最近在B部门做项目，用到的平台框架都是基于单进程模式的，在以前的A部门做过的项目都是多线程模式的，在使用的过程中，也思考了一些问题，引发了对这两种类型的线程的对比和自己的一些看法（仅是个人观点）。

先讲下单进程模式和多线程模式的优劣：

1.单进程开发简单；多线程开发复杂

2.单进程在处理高并发时一般采用多启动进程的方式；多线程仅需启动多个线程。进程的切换开销比线程大

3.多进程之间如果有信息通信则相对多线程效率较低，因为多线程属于同一地址空间的访问，效率相对较高（暂不涉及锁等一致性策略的影响）

4.多进程稳定好，一个进程死了不影响其他进程；多线程中，任意一个出现问题，将影响到所有。

5。。。

 

最近的项目中使用框架app platform（后面简称AP框架），了解到它的实现是单进程模拟用户空间多线程的方式，这个手法在学习计算机OS的时候都有接触过，就是CPU时间分片，模拟用户多任务并发。该框架也是使用了这种，它的级别不是进程间，而是进程内模拟。

研究了下，模型简单化：请求-> 接收-> 处理 ->发送  大体框架流程如下：

 

AP框架原来的设计是完整的接收到数据包，然后调用用户的处理代码，最后再将数据包提交到发送队列。这样的话，因为是单线程，所以在处理一个远程调用时（用户接口），需要等待接收完整的数据，无法从用户接口直接退出切换到主线程，那么对其他有事件到来的请求将被阻塞，不能很快的被处理，吞吐量必然会很低。对于大多数业务部门的代码逻辑，任务都是轻量级的，最主要的瓶颈在IO上。原来的架构在IO上不能够及时处理，导致阻塞，有了保存请求上下文（参见libpth）的方法之后，当前的请求在收发数据包未完成且需要等待时，主动调用schedule方法，