多进程和多线程的使用场景

多进程和多线程的使用场景

多进程模型的优势是CPU，多线程模型的优势是线程间切换代价较小

多线程模型适用于I/O密集型的工作场景，因此I/O密集型的工作场景经常会由于I/O阻塞导致频繁的切换线程。同时，多线程模型也适用于单机多核分布式场景。

多进程模型，适用于CPU密集型。同时，多进程模型也适用于多机分布式场景中，易于多机扩展。

一. 两者区别

进程是资源分配的基本单位；线程是系统调度和分派的基本单位。
属于同一进程的线程，堆是共享的，栈是私有的。
属于同一进程的所有线程都具有相同的地址空间。

多进程的优点：
①编程相对容易；通常不需要考虑锁和同步资源的问题。
②更强的容错性：比起多线程的一个好处是一个进程崩溃了不会影响其他进程。
③有内核保证的隔离：数据和错误隔离。 对于使用如C/C++这些语言编写的本地代码，错误隔离是非常有用的：采用多进程架构的程序一般可以做到一定程度的自恢复；（master守护进程监控所有worker进程，发现进程挂掉后将其重启）。

多线程的优点：
①创建速度快，方便高效的数据共享
共享数据：多线程间可以共享同一虚拟地址空间；多进程间的数据共享就需要用到共享内存、信号量等IPC技术。
②较轻的上下文切换开销 - 不用切换地址空间，不用更改寄存器，不用刷新TLB。
③提供非均质的服务。如果全都是计算任务，但每个任务的耗时不都为1s，而是1ms-1s之间波动；这样，多线程相比多进程的优势就体现出来，它能有效降低“简单任务被复杂任务压住”的概率。

二. 应用场景

1. 多进程应用场景
   nginx主流的工作模式是多进程模式（也支持多线程模型）
   几乎所有的web server服务器服务都有多进程的，至少有一个守护进程配合一个worker进程，例如apached,httpd等等以d结尾的进程包括init.d本身就是0级总进程，所有你认知的进程都是它的子进程；
   chrome浏览器也是多进程方式。 （原因：①可能存在一些网页不符合编程规范，容易崩溃，采用多进程一个网页崩溃不会影响其他网页；而采用多线程会。②网页之间互相隔离，保证安全，不必担心某个网页中的恶意代码会取得存放在其他网页中的敏感信息。）
   redis也可以归类到“多进程单线程”模型（平时工作是单个进程，涉及到耗时操作如持久化或aof重写时会用到多个进程）
2. 多线程应用场景
   线程间有数据共享，并且数据是需要修改的（不同任务间需要大量共享数据或频繁通信时）。
   提供非均质的服务（有优先级任务处理）事件响应有优先级。
   单任务并行计算，在非CPU Bound的场景下提高响应速度，降低时延。
   与人有IO交互的应用，良好的用户体验（键盘鼠标的输入，立刻响应）
   案例：
   桌面软件，响应用户输入的是一个线程，后台程序处理是另外的线程；
   memcached
3. 选什么？
   ①需要频繁创建销毁的优先用线程（进程的创建和销毁开销过大）
   这种原则最常见的应用就是Web服务器了，来一个连接建立一个线程，断了就销毁线程，要是用进程，创建和销毁的代价是很难承受的

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

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

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

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

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