多进程 or 多线程

什么是多线程？

多线程是为了使得多个线程并行的工作以完成多项任务，以提高系统的效率。线程是在同一时间需要完成多项任务的时候被实现的。

使用线程的好处有以下几点：

• 使用线程可以把占据长时间的程序中的任务放到后台去处理
• 用户界面可以更加吸引人，这样比如用户点击了一个按钮去触发某些事件的处理，可以弹出一个进度条来显示处理的进度
• 程序的运行速度可能加快
• 在一些等待的任务实现上如用户输入、文件读写和网络收发数据等，线程就比较有用了。在这种情况下我们可以释放一些珍贵的资源如内存占用等等。

进 程是程序在计算机上的一次执行活动。当你运行一个程序，你就启动了一个进程。显然，程序是死的(静态的)，进程是活的(动态的)。进程可以分为系统进程和 用户进程。凡是用于完成操作系统的各种功能的进程就是系统进程，它们就是处于运行状态下的操作系统本身；用户进程就不必我多讲了吧，所有由你启动的进程都 是用户进程。进程是操作系统进行资源分配的单位。

在Windows下，进程又被细化为线程，也就是一个进程下有多个能独立运行的更小的单位。

在同一个时间里，同一个计算机系统中如果允许两个或两个以上的进程处于运行状态，这便是多任务。现代的操作系统几乎都是多任务操作系统，能够同时管理多个进 程的运行。 多任务带来的好处是明显的，比如你可以边听mp3边上网，与此同时甚至可以将下载的文档打印出来，而这些任务之间丝毫不会相互干扰。那么这里就涉及到并行 的问题，俗话说，一心不能二用，这对计算机也一样，原则上一个CPU只能分配给一个进程，以便运行这个进程。我们通常使用的计算机中只有一个CPU，也就 是说只有一颗心，要让它一心多用，同时运行多个进程，就必须使用并发技术。

实现并发技术相当复杂，最容易理解的是“时间片轮转进程调度算法”，它的思想简 单介绍如下：在操作系统的管理下，所有正在运行的进程轮流使用CPU，每个进程允许占用CPU的时间非常短(比如10毫秒)，这样用户根本感觉不出来 CPU是在轮流为多个进程服务，就好象所有的进程都在不间断地运行一样。但实际上在任何一个时间内有且仅有一个进程占有CPU。

如果一台计算机有多个CPU，情况就不同了，如果进程数小于CPU数，则不同的进程可以分配给不同的CPU来运行，这样，多个进程就是真正同时运行的，这便是并行。但如果进程数大于CPU数，则仍然需要使用并发技术。

在Windows中，进行CPU分配是以线程为单位的，一个进程可能由多个线程组成，这时情况更加复杂，但简单地说，有如下关系：

• 总线程数<= CPU数量：并行运行
• 总线程数 > CPU数量：并发运行

并行运行的效率显然高于并发运行，所以在多CPU的计算机中，多任务的效率比较高。但是，如果在多CPU计算机中只运行一个进程(线程)，就不能发挥多CPU的优势。

这里涉及到多任务操作系统的问题，多任务操作系统(如Windows)的基本原理是:操作系统将CPU的时间片分配给多个线程,每个线程在操作系统指定的时 间片内完成(注意,这里的多个线程是分属于不同进程的).操作系统不断的从一个线程的执行切换到另一个线程的执行,如此往复,宏观上看来,就好像是多个线 程在一起执行.由于这多个线程分属于不同的进程,因此在我们看来,就好像是多个进程在同时执行,这样就实现了多任务。

架构设计：多进程还是多线程

就像莎士比亚的“To be, or not to be, that is the question”始终困扰着哈姆雷特，对于“进程还是线程？”这个问题，也经常困扰着那些进行软件架构设计的家伙。所以今天打算聊一下我对这个问题的体 会。假如你还搞不清楚线程和进程的区别，请先找本操作系统原理的书好好拜读一下，再回来看帖。

　　由于这个问题很容易引发口水战，事先声明如下：多进程和多线程，无法一概而论地说谁比谁好。因此本帖主要描述特定场景（与我所负责的产品相关）下，进程和线程的权衡经验，仅供大伙儿参考。
　　
　　上面说了一大堆，其实有不少的应用系统符合上述特点，比如：某些网络游戏服务器、某些金融行业的业务系统、某些电子商务的交易系统等等。如果你正在从事的是类似的应用系统的设计，希望我下面介绍的经验对你有帮助。

进程颗粒度问题

大伙儿应该明白，进程和线程都是处理并发（concurrency）的手段。对于上述这种比较复杂的系统，如果你企图全部用进程（见注1）或者 全部用线程（见注2）来处理并发，估计会死得很难看。所以，关键问题就是如何在进程和线程之间进行平衡（也就是确定进程颗粒度的问题）。

我个人建议，尽量以业务逻辑的单元来划分进程。这样做的好处有如下几点：

1、 避免扯皮

一般来说，某个固定业务逻辑的开发人员也是相对固定的。如果业务逻辑对应的某个进程崩溃了，测试人员容易快速定位肇事者，然后直接提交Bug给他/她。

　　反之，一个进程搞得太庞大，N多人掺和在里面，一旦进程崩溃了，相关编程人员之间很容易互相扯皮，不利于维护安定团结的局面；另外，由于测试人员经常搞不清楚Bug属于谁，经常给错Bug，也容易制造人民内部矛盾。
　　
　　从上面可以看出来，相对细的进程颗粒度能够避免一些管理上的麻烦。由于XXX经常教导我们：“稳定压倒一切”，所以该优点列第一条。

2、 健壮性、容错性

　　一般来说，开发人员的水平参差不齐，优秀的毕竟是少数（具体参见“二八原理系列”的帖子）。所以难免会有菜鸟程序员搞出低级错误，而有些低级错误是致命的，会导致进程的崩溃。
　　
　　如果你是以业务逻辑划分进程，一个业务逻辑的进程崩溃，对其它业务逻辑的影响不大（除非是该业务逻辑的依赖方）；因此就不会出现“注2”提到的问题。

3、分布式

　　我常碰见的分布式部署需求，一般都是按照业务逻辑的维度来划分。比如系统中有一个认证模块，里面包含有敏感的用户认证信息。这时候客户就会要求把该模块单独部署在一台经过安全加固的主机中（以防阶级敌人搞破坏）。
　
　　另外，支持分布式部署还可以顺带解决性能问题。比如某个业务逻辑模块特别消耗硬件资源（比如内存、CPU、硬盘、带宽），就可以把它拿出去单独放一台机器上跑。

4、跨编程语言
　　这个好处可能很多人容易忽略。一般来说，每个编程语言都有各自的优缺点。如果你通过业务逻辑划分进程，就可以根据不同的业务逻辑的特点来选择合适的编程语言。
　　
　　比如：对于性能敏感的模块，我就使用C++搞定；而对于一些业务逻辑密集型的模块，则使用Java或Python开发。

进程间通讯问题

　　既然不可能把整个系统放入一个进程，那就必然会碰到IPC的问题。下面就来说一下该如何选择IPC。
　　
　　各种操作系统里面，有很多稀奇古怪的IPC类型。由于要考虑跨平台，首先砍掉一批（关于IPC的跨平台问题，我在“跨平台开发”系列中会提 到）。剩下的IPC类型中，能够进行数据传输的IPC就不多了，主要有如下几种：套接字（以下简称Socket）、共享内存、管道、文件。
　　
　　其中Socket是我强烈推荐的IPC方式，理由如下：使用Socket可以天然地支持分布式部署；使用Socket可以比较容易地实现多种编 程语言的混合（比如C++、Java、Python、Flex都支持Socket）；使用Socket还可以省掉了一大坨“锁操作”的代码。
　　
　　列位看官中，或许有人在担心Socket的性能问题，其实大可不必多虑。当两个进程在本机上进行Socket通讯时，由于可以使用 localhost环回地址，数据不用经过物理网卡，操作系统内核还可以进行某些优化。这种情况下，Socket相对其它几种IPC机制，不会有太大的性 能偏差。
　　
　　最后再补充一下，Socket方式也可以有效防止扯皮问题。举个例子：张三写了一个进程A，李四写了一个进程B，进程A通过Socket方式发 数据给进程B。突然有一天，两个进程的通讯出故障了。然后张三就说是李四接收数据出错；李四就说张三发送数据出错。这时候怎么办捏？很简单，随便找个 Sniffer软件当场抓一下数据包并Dump出来看，问题就水落石出了。

为啥还要线程？

上面说了这么多进程的好处，有同学要问了：“那线程有什么用捏？”总的来说，使用线程出于两方面的考虑：性能因素和编码方便。

1、性能因素
　　由于某些操作系统（比如Windows）中的进程比较重型，如果频繁创建进程或者创建大量进程，会导致操作系统的负载过高。举例如下：
　　假设你要开发一个类似Web Server的应用。你针对每一个客户端请求创建一个对应的进程用于进行数据交互（是不是想起了古老的CGI :-）。一旦这个系统扩容，用户的并发连接数一增加，你的应用立马死翘翘。
　　上面的例子表明，跨平台软件系统的进程数要保持相对稳定。如果你的进程数会随着某些环境因素呈线性增长，那就相当不妙了（顺带说一下，如果线程数会随着环境因素呈线性增长，也相当不妙）。而根据业务逻辑的单元划分进程，顺便能达到“进程数的相对稳定”的效果。
　　
2、编码方面
　　由于业务逻辑内部的数据耦合比较紧密。如果业务逻辑内部的并发也用进程来实现，可能会导致大量的IPC编码（任意两个进程之间只要有数据交互，就得写一坨IPC代码）。这或许会让相关的编程人员怨声载道。
　　当然，编码方面的问题也不是绝对的。假如你的系统有很成熟且方便易用的IPC库，可以比较透明地封装IPC相关操作，那这方面的问题也就不存在了。

鱼还是熊掌：浅谈多进程多线程的选择

关于多进程和多线程，教科书上最经典的一句话是“进程是资源分配的最小单位，线程是CPU调度的最小单位”。这句话应付考试基本上够了，但如果在工作中遇到类似的选择问题，那就没有这么简单了，选的不好，会让你深受其害。

经常在网络上看到有的XDJM问“多进程好还是多线程好？”、“Linux下用多进程还是多线程？”等等期望一劳永逸的问题，我只能说：没有最好，只有更好。根据实际情况来判断，哪个更加合适就是哪个好。

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

看起来比较简单，优势对比上是“线程 3.5 v 2.5 进程”，我们只管选线程就是了？
呵呵，有这么简单我就不用在这里浪费口舌了，还是那句话，没有绝对的好与坏，只有哪个更加合适的问题。我们来看实际应用中究竟如何判断更加合适。

• 需要频繁创建和销毁的优先用线程（进程的创建和销毁开销过大）
  这种原则最常见的应用就是Web服务器了，来一个连接建立一个线程，断了就销毁线程，要是用进程，创建和销毁的代价是很难承受的

• 需要进行大量计算的优先使用线程（CPU切换频繁）
  所谓大量计算，当然就是要耗费很多CPU，切换频繁了，这种情况下线程是最合适的。
  这种原则最常见的是图像处理、算法处理。

• 强相关使用线程，弱相关使用进程
  什么叫强相关、弱相关？理论上很难定义，给个简单的例子就明白了。
  一般server需要完成以下任务：消息收发、消息处理。“消息收发”和“消息处理”就是弱相关的任务，而“消息处理”里面可能又分为“消息解码”、“业务处理”，这两个任务相对来说相关性就要强多了。因此“消息收发”和“消息处理”可以分进程设计，“消息解码”、“业务处理”可以分线程设计。
  当然这种划分方式不是一成不变的，也可以根据实际情况进行调整。

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

• 都满足需求的情况下，用你最熟悉、最拿手的方式
  至于“数据共享、同步”、“编程、调试”、“可靠性”这几个维度的所谓的“复杂、简单”应该怎么取舍，我只能说：没有明确的选择方法。但我可以告诉你一个选择原则：如果多进程和多线程都能够满足要求，那么选择你最熟悉、最拿手的那个。
  需要提醒的是：虽然我给了这么多的选择原则，但实际应用中基本上都是“进程+线程”的结合方式，千万不要真的陷入一种非此即彼的误区。

多进程、多线程实验

参考：

多进程 or 多线程
我理解的多进程和多线程
编程思想之多线程与多进程(1)——以操作系统的角度述说线程与进程
服务端编程中多线程的应用