一周技术思考笔记(第48期)-多进程单线程还是单进程多线程

观察了周围，工作了几年，大部分人都是埋着头拉车，而不愿去抬头思考一下，思考spring为什么能够管理那么多的javabean，思考Tomcat为什么能够把用户的请求转发给java类，这些都是怎么做到的。

但毕竟还是有一些人会去这样思考的，这周微信上有人问，Nginx是多进程单线程，Tomcat是单进程多线程，为什么它们会这样设计。

是呀，为什么会这样设计呢。

我当时是这么回答的。

我理解是这样，Nginx的用途常作为代理，多进程单线程，一般是通过epoll机制，很适合，IO下这就省去了并发情况下的加锁以及线程的切换带来的性能损耗。Tomcat 实际上也在学习这个方向，所有在后来的版本中引入了NIO。

但是Tomcat 版本是在太重 估计也没有可能推到重来。

另外他们俩担负的责任也不同，代理一版都是比较轻型，Tomcat毕竟要担负起处理负责业务逻辑的职责，多个进程恐怕不好协同哈，跨进程共享变量，那就成了分布式了。

后来我再想，估计还有一个本质的原因，Nginx作为web代理服务器，主要目的是IO，进行网络请求的收发，没有状态而言，“酒肉穿肠过”。Tomcat作为Java容器，主要目的是处理业务逻辑，需要做很多业务的计算逻辑的处理，需要处理各种业务数据状态，如果是多进程，那就相当于“牛郎望织女”，中间还隔了条银河。

再啰嗦一下。

Nginx作为web代理服务器，专注网络收发，属于“IO密集型”。

多进程单线程模型，一个master进程，多个work进程，另外work进程可以绑定到独立的CPU上，这样避免了进程的切换成本。每个进程内部由一个线程来处理请求，负责请求的吞吐。

但是，毕竟IO是有等待的，有快有慢，如果遇到慢的IO，还是担心一个线程忙不过来，怎么办。Nginx就利用了Linux的epoll机制，采用IO多路复用来提高CPU的利用率。

Tomcat作为java容器，专注业务计算，属于“CPU密集型”。

那就是除了接收请求，返回请求之外，还需要在这期间处理业务逻辑，相对于只顾IO收发，处理业务逻辑的耗时就长很多了，尤其再遇到更复杂的业务逻辑处理。

可能到这里，你还是觉得，请求分别进入多进程内部一样可以处理耗时的操作，但是，还有一点，业务是需要处理状态数据的，比如订单的状态流转等等，往往这样的状态数据需要被共享。

当然Tomcat在后来的版本中也引入了NIO的线程模型，可以更进一步提高系统的吞吐。

多进程单线程的模型中，没有了线程的切换，因此性能上能减少很多不必要的消耗，所以Nginx这样的代理服务的系统性能也能够提升很多。

多线程就好比一条流水线有多个机械手，把一件事情中途交给其他线程处理，要交接处理中间状态信息。

单进程就好比一条流水线只有一个机械手，切换时间片时暂停状态就可以，不用交接信息，减少无用功，所以效率高。

上下文切换的成本来自哪里。

当从一个任务切换到另一个任务，当前任务的上下文，如堆栈，指令指针等都要保存起来，以便下次任务时恢复，然后再把另一个任务的堆栈加载进来，如果有大量的上下文切换，就会影响性能。

线程切换需要进行系统调用。需要从用户态->内核态->用户态。上下文切换，需要保存寄存器中的信息，以便于完成系统调用后还原现场。会多跑很多指令，出入栈会比寄存器慢很多。相对来说开销就很大了。

CPU要保存当前的状态，再恢复原来的状态，当线程多的时候，累积的成本自然就水涨船高了。

程序就是人写的各种代码，告诉计算机需要做什么事情，只需要存储资源。当程序运行起来的时候，需要的不光是存储资源，还有其他的为了弥补速度差这些东西都以各种寄存器的形式存在，比如：指令寄存器、地址寄存器、数据寄存器、程序计数器等等。

----END----

这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。

与爱学习、爱思考、爱记录的你共勉。

参考资料：

本文图1选自罗剑锋.“Nginx：高性能的Web服务器”https://time.geekbang.org/column/article/117492

本文图2选自佘志东.“高性能优化：单机java极致优化”.https://time.geekbang.org/column/article/429098

https://time.geekbang.org/column/article/8805