Java ThreadPoolExecutor 线程池 tips 1：单线程吞吐量来估计系统的线程数目

问题：我们需要多大的线程池

java中的线程池想必都用过，最简单的是通过Executors工厂方法得到线程池，比如固定池大小，task缓冲为无限大小的队列

[java]
view plaincopy

ExecutorService pool = Executors.newFixedThreadPool(poolSize);
...
pool.execute(new Handler(serverSocket.accept()));

实际应用中使用线程池时，第一个问题是：我们需要多大的线程池？

根据单线程的吞吐量来估计线程池的大小

假如我们有一些批处理任务需要完成，根据每个任务的处理时间和需要处理的任务数目(单位时间)很容易计算出需要的线程数目。

	Task1	Task2
每秒需要处理的任务数目	5 task/s	10 task/s
每个任务的处理时间	3 s	2.4 s
每个任务的处理速度	0.3 task/s	0.416 task/s
线程数目	5 /0.3 = 15	10/0.416 = 24

举个例子，在麦当劳点餐时，假如每个顾客的平均点餐是30秒,如果开单个窗口，则每分钟能接受两个顾客的点餐。麦当劳的订单处理是每分钟10位顾客，所以麦当劳经理希望每分钟接受10顾客的点餐。因此这个麦当劳餐厅需要设置5个窗口来保证其供应系统的满负荷。

问题：并发编程中，单CPU最佳线程数是多少？

在考虑最佳线程数时，网络上的建议往往是从任务的类型来决定单CPU的最佳线程。如果任务是CPU密集型或者说是计算密集型的，那么单个线程/CPU让系统满负荷。

反之，如果任务是IO-bound，则需要多个线程来避免CPU因为等待IO而闲置。

个人觉得这里的IO-Bound理解为non-cpu bound更为贴切，可能在实际系统中，IO (disk, network)往往是系统的主要瓶颈，所以人们往往使用IO-bound来和CPU-bound进行比较。

淘宝开发人员蒋江伟(小邪)在<服务器端性能优化>中给过一个计算公式

最佳线程数量=((线程等待时间+线程cpu时间)/线程cpu时间) * cpu数量

这个公式实际上是cpu时间和非cpu时间之间的一个比例。

在slides中小邪提了一个观点是

如果要提升服务器端的响应时间RT，采用减少IO的时间能达到最佳效果，比如合并多个IO请求
如果要提升QPS，采用优化CPU的时间能达到最佳效果。比如响应时间(任务处理时间)是90ms，其中IO为80ms，cpu为10ms，如果将cpu缩减为5ms，则系统的吞吐量可以提高一倍。根据公式 QPS = 1/RT，上述结论当然不正确。其给出的解释是，cpu缩减为5ms后，线程数可以增加一倍，线程的增加导致了系统的吞吐量的大幅提高。

流水线中的吞吐量公式比较, pipeline throughtput = 1 instr / Max (stage time)，流水线中的最耗时部分决定了流水线的吞吐量。

而上面的公式是系统的最快的部分(cpu)决定了系统的吞吐量，是不是矛盾？

麦当劳的例子：假如点餐需要30 seconds，处理单子需要6 seconds，30/6=5个窗口

如果将处理单子速度提供一倍，3秒钟响应一个，则可以开30/3=10个窗口，系统的吞吐量加倍。

系统的最快部分(CPU)定义了系统的边界，这个边界形成一个理论上本文开始提到的每秒需要处理的任务数目。

而系统中的等待时间(非CPU)近似为系统的response time/latency(假定非cpu时间占大头)，同边界时间之比，即为系统所需要的并发数。

又假定并发数越多，系统的吞吐量越大，所以优化cpu时间能导致QPS的大幅提升。

上述公式的本质如下图：增加系统中耗时部分(IO)的并发数，使系统的吞吐量和系统中最快部分(cpu)的速度一致。如果是多核，相当于最快部分(cpu)增加了并发，相应的耗时部分并发数乘上相应的系数(cpu数量).

实际情况是：我们是增加相应的线程(并发任务数)，而并不是增加了系统的IO设备。