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

http://blog.csdn.net/pecywang/article/details/8682431

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

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

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

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

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

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

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

5。。。

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

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

AP框架原来的设计是完整的接收到数据包，然后调用用户的处理代码，最后再将数据包提交到发送队列。这样的话，因为是单线程，所以在处理一个远程调用时(用户接口)，需要等待接收完整的数据，无法从用户接口直接退出切换到主线程，那么对其他有事件到来的请求将被阻塞，不能很快的被处理，吞吐量必然会很低。对于大多数业务部门的代码逻辑，任务都是轻量级的，最主要的瓶颈在IO上。原来的架构在IO上不能够及时处理，导致阻塞，有了保存请求上下文(参见libpth)的方法之后，当前的请求在收发数据包未完成且需要等待时，主动调用schedule方法，保存现场，出让cpu。对每个请求而言，它看到的是自己一直在运行，而对系统而言，挂起需等待的请求，处理另外一个数据已经到来的请求，肯定效率会更高一些，并发度也会提高很多。

实际上对于IO的设计一直是高吞吐网络应用程序设计的关键，一般是采用Reactor模式，在Linux中大部分使用select或epoll，并将IO单独交由一个或多个线程来处理，把IO和用户逻辑分开，使得他们能高效执行。

AP框架正是有效的利用了网络收发这段等待时间来处理其他任务，进一步提高了效率和并发度，实现上和CPU出让时间片的方法是类似的，单线程模拟用户多任务。

但单线程还是单线程，即使提高了IO的收发效率，用户的逻辑比较轻，也是存在一定问题的。AP框架作者把这个实现在单进程里面，且用户的请求切换都是在用户态进行的，开销很小。作者当时也考虑过多线程的实现方法，但担心多线程的内核态切换开销过大，影响性能，所以没有采用。据说也做了实验，性能很差，所以就否定了。不过我注意到作者当时在测试时采用的模型是2个线程分别管理收发，队列里有多少个请求就开启多少个线程，请求和线程是1：1的，这样当请求过多时就会导致进程内线程非常多，线程切换的开销也会随之变得很大。这在谁看来都是不太能够接受的方案。

作者这里的线程1:1方案本身设计上就有问题，业务逻辑很轻，为什么把使用一个线程池(线程池线程几个应该就可以，无需1：1)呢，当接收数据线程R，每收到部分数据时就将数据包投递到线程池线程的队列中，并从epoll中删除，由线程池线程来判断数据包是否结束(数据包完整由用户来判断，框架本身无法知道)，如果数据包不完整，继续投递到R线程的epoll接收队列。完整的数据包由线程池线程处理后直接投递到发送线程S，这样各司其责，收发线程只处理和IO有关的，线程池线程处理用户逻辑。想必性能不会差到哪里去。

以上所讲的内容都是在当前的多核server下的，服务器都是8核，16核甚至更多，将上面的线程分别绑定到不同的CPU上，线程间仅需较小粒度的锁即可保证数据一致性，整体性能应该会有不错的表现。AP框架的模式可以解决大部分问题，性能应该还是可以继续提高。

(我没有做测试实验，仅是个人的理论分析，欢迎批评指正)