就像莎士比亚的“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类型中，能够进行数据传输的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 进程”，我们只管选线程就是了？
呵呵，有这么简单我就不用在这里浪费口舌了，还是那句话，没有绝对的好与坏，只有哪个更加合适的问题。我们来看实际应用中究竟如何判断更加合适。
1）需要频繁创建销毁的优先用线程
原因请看上面的对比。
这种原则最常见的应用就是Web服务器了，来一个连接建立一个线程，断了就销毁线程，要是用进程，创建和销毁的代价是很难承受的
2）需要进行大量计算的优先使用线程
所谓大量计算，当然就是要耗费很多CPU，切换频繁了，这种情况下线程是最合适的。
这种原则最常见的是图像处理、算法处理。
3）强相关的处理用线程，弱相关的处理用进程
什么叫强相关、弱相关？理论上很难定义，给个简单的例子就明白了。
一
般的Server需要完成如下任务：消息收发、消息处理。“消息收发”和“消息处理”就是弱相关的任务，而“消息处理”里面可能又分为“消息解码”、“业
务处理”，这两个任务相对来说相关性就要强多了。因此“消息收发”和“消息处理”可以分进程设计，“消息解码”、“业务处理”可以分线程设计。
当然这种划分方式不是一成不变的，也可以根据实际情况进行调整。
4）可能要扩展到多机分布的用进程，多核分布的用线程
原因请看上面对比。
5）都满足需求的情况下，用你最熟悉、最拿手的方式
至于“数据共享、同步”、“编程、调试”、“可靠性”这几个维度的所谓的“复杂、简单”应该怎么取舍，我只能说：没有明确的选择方法。但我可以告诉你一个选择原则：如果多进程和多线程都能够满足要求，那么选择你最熟悉、最拿手的那个。
需要提醒的是：虽然我给了这么多的选择原则，但实际应用中基本上都是“进程+线程”的结合方式，千万不要真的陷入一种非此即彼的误区。
转自：http://blog.csdn.net/jw212/article/details/5928995