并发模型编程中多进程与多进程的选择

在进行并发程序的实现时我们经常面临一个问题，到底是该选择多线程并发模型还是多线程并发模型呢？要在这两者间进行一个选择，首先需要明白两者的优缺点：

多线程的优点

• 方便高效的内存共享 – 多进程下内存共享比较不便，且会抵消掉多进程编程的好处。
• 较轻的上下文切换开销 – 不用切换地址空间，不用更改CR3寄存器，不用清空TLB。

多进程的优点

• 更强的容错性 – 一个进程crash不会导致整个系统崩溃。
• 更好的多核可伸缩性 – 进程的使用将许多内核资源（如地址空间，页表，打开的文件）隔离，在多核系统上的可伸缩性强于多线程程序。

举例说明

从上面的对照，我们对两者的特点有个整体上的认识，若使用交通系统来举例子则

• 多进程是立体交通系统，虽然造价高，上坡下坡多耗点油，但是不堵车。
• 多线程是平面交通系统，造价低，但红绿灯太多，老堵车。

应该说，多线程比多进程成本低，但性能更低

下面通过两个经典的应用场景来做进一步的对照：

Memcached使用多线程

一个常用的开源缓存框架memcached其使用的模型为单进程多线程，memchched进程启动后，用户写入这个cache的所有内容都是写在这个进程的堆空间中。换言之所有的数据都是集中存在于唯一一个进程空间中，这样各个线程完全可以共享这些数据，可以全部的去查询和修改。 而如果我们换用多进程来实现的话，那用户传入cache的数据都存放在哪里？传过来后是一个进程来处理的，那处理结果必然存在这个进程自己的内存空间中，这样别的进程想读取的话怎么办？使用进程间通信？消耗得多大！

正是因为多进程各自的内存空间是独立的，导致传入的数据也是相互独立的，而不是存放在一起的！这样想跨进程查询的话就得IPC，而且及其频繁，而且还不知道是该查哪个子进程的空间！所以这种方式明摆着不合适，故使用多线程来实现。

Nginx使用多线程

Nginx作为一个HTTP服务器，其为多个客户端提供服务，多进程的话各个进程之间相互独立，一个进程crash不会影响其他进程；而多线程：任何一个子线程crash了，其他子线程就全部crash！这意味着：使用多线程的话：各个用户的请求处理是相互影响的，一个挂了，其他人的请求也跟着悲剧；而多进程就不会相互影响！ 所以更适合使用多进程！

小结

在能使用多进程解决一个问题的时候不要使用多线程；只有在牵扯到全局数据写入/更新的操作，再使用多线程。