附1：多线程并发方案的不足——响应式Spring的道法术器

本系列其他文章见：《响应式Spring的道法术器》。
本篇内容是响应式流的附录。

（以下接响应式流的1.2.1.1节，关于“CPU眼中的时间”的内容。请不要单独看这一篇内容，否则有些内容可能让你摸不着头脑 0…0）

多线程的方式有其不完美之处，而且有些难以驾驭——

一、耗时的上下文切换

CPU先生不太乐意切换进程，每次换进程的时候都需要一个小时，因为每次切换进程的时候，办公桌上所有的资料（进程上下文）都要重新换掉。但是每个进程都必须雨露均沾地照顾到，要不客户就不满意了。

操作系统部很贴心，进程任务里边又可以分成一批线程子任务，如果某个线程子任务在等待I/O和网络的数据，就先放一边换另一个线程子任务去做，而不是切换整个进程。切换线程任务是一种相对轻量级的操作，因为不同的线程任务的许多数据都是共享的，所以只需要更新线程相关的数据，不用完全重新整理办公桌。即便如此也需要将近半小时的切换时间，以便能够“熟悉”任务内容。

不过毕竟，CPU先生的工作逐渐充实起来了。如图：

注意到图中CPU的时间条中深褐色的为上下文切换的时间，可以想见，高并发情况下，线程数会非常多，那么上下文切换对资源的消耗也会变得明显起来。况且在切换过程中，CPU并未执行任何业务上的或有意义的计算逻辑。

这里我们没有关注线程的创建时间，因为应用通常会维护一个线程池。需要新的线程执行任务的时候，就从线程池里取，用完之后返还线程池。类似的，数据库连接池也是同样的道理。

通过这个图，我们可以得到估算线程池的大小的方法。为了让CPU能够恰好跑满，Java Web服务器的最佳工作线程数符合以下公式：

$$(1+$$