多线程与多进程

多线程与多进程的比较

关于多进程和多线程，教科书上最经典的一句话是

进程是资源分配的最小单位，线程是CPU调度的最小单位

这句话应付考试基本上够了，但如果在工作中遇到类似的选择问题，那就没有这么简单了，选的不好，会让你深受其害。

我们按照多个不同的维度，来看看多线程和多进程的对比(注：因为是感性的比较，因此都是相对的，不是说一个好得不得了，另外一个差的无法忍受)。

看起来比较简单，优势对比上是“线程 3.5 v 2.5 进程”，我们只管选线程就是了?

呵呵，有这么简单我就不用在这里浪费口舌了，还是那句话，没有绝对的好与坏，只有哪个更加合适的问题。我们来看实际应用中究竟如何判断更加合适。

1)需要频繁创建销毁的优先用线程

原因请看上面的对比。

这种原则最常见的应用就是Web服务器了，来一个连接建立一个线程，断了就销毁线程，要是用进程，创建和销毁的代价是很难承受的

2)需要进行大量计算的优先使用线程

所谓大量计算，当然就是要耗费很多CPU，切换频繁了，这种情况下线程是最合适的。

这种原则最常见的是图像处理、算法处理。

3)强相关的处理用线程，弱相关的处理用进程

什么叫强相关、弱相关?理论上很难定义，给个简单的例子就明白了。

一般的Server需 要完成如下任务：消息收发、消息处理。“消息收发”和“消息处理”就是弱相关的任务，而“消息处理”里面可能又分为“消息解码”、“业务处理”，这两个任 务相对来说相关性就要强多了。因此“消息收发”和“消息处理”可以分进程设计，“消息解码”、“业务处理”可以分线程设计。

当然这种划分方式不是一成不变的，也可以根据实际情况进行调整。

4)可能要扩展到多机分布的用进程，多核分布的用线程

原因请看上面对比。

5)都满足需求的情况下，用你最熟悉、最拿手的方式

至于“数据共享、同步”、“编程、调试”、“可靠性”这几个维度的所谓的“复杂、简单”应该怎么取舍，我只能说：没有明确的选择方法。但我可以告诉你一个选择原则：如果多进程和多线程都能够满足要求，那么选择你最熟悉、最拿手的那个。

需要提醒的是：虽然我给了这么多的选择原则，但实际应用中基本上都是“进程+线程”的结合方式，千万不要真的陷入一种非此即彼的误区。

1、多进程与多线程的简单比较

多进程

优点：内存隔离，单个进程的异常不会导致整个应用的崩溃。方便测试，编程简单。

缺点：进程间调用，通讯和切换均比多线程大，耗资源。

使用场所：目标子动能交互少，如果资源和性能许可，可以设计由多个子应用程序来组合完成目的。

多线程

优点：提高系统的并行性，并且开销小。数据共享方便(不需要进程间的通信)

缺点：没有内存隔离，单个现成的崩溃会导致整个应用程序的退出，发生采内存等bug时，定位及其不方便。编程复杂;调试困难;线程执行的随机性可能导致逻辑混乱，甚至发生死锁现象;

使用场所：在存在大量IO，网络等耗时操作，或者需要和用户交互时，使用多线程有利于提高系统的并行性和用户界面快速响应从而提高友好性。

2、设计时应注意的事项

尽量避免长驻内存的进程，例如那些很少用到的功能，或周期性很长(10分钟以上)，

把它们的功能提取出来，做成一个小的应用程序。需要的时候再把它们拉起来(如通过crontab配置，或直接system)。

把目标设计成子功能系统的组合可用提高重用的易用性和维护性。

把目标根据功能划分不同的子系统，子系统间遵循特定的协议(文本或XML)，由通讯联系起来，协作完成目标。

典型的案例就是UNIX或LINUX的工具使用。如：$ cat veglist fruitlist | sort > clist，用cat打开文件，协议是字符流，通过管道(通讯手段)传给sort进行排序，把排序的结果流重定向到文件中。这种自由组合协作风格应用思想和编程思路也是吸引众多UNIX拥护者的原因之一吧。

在软件设计中，选择多进程还是多线程还跟很多因素有关，例如对数据实时处理的性能要求、对健壮性和安全性要求、是否要求跨平台(包括操作系统和数据库)及是否需要分布部署。因此，在设计中应充分考虑各种因素以求做到最大利用系统资源。