多线程的使用场景

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

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

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

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

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

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

1.1 多线程应该最多的场景：

web服务器本身； 各种专用服务器（如游戏服务器）；

1.2多线程的常见应用场景：

1、后台任务，例如：定时向大量（100w以上）的用户发送邮件； 2、异步处理，例如：发微博、记录日志等； 3、分布式计算