如何合理地估算线程池大小

CPU密集型

CPU密集型也叫计算密集型，指的是系统的硬盘、内存性能相对CPU要好很多，此时，系统运作大部分的状况是CPU Loading 100%，CPU要读/写I/O(硬盘/内存)，I/O在很短的时间就可以完成，而CPU还有许多运算要处理，CPU Loading很高。写了一个cpu密集型的例子,一直执行自增操作CPU bound的程序一般而言CPU占用率相当高。这可能是因为任务本身不太需要访问I/O设备，也可能是因为程序是多线程实现因此屏蔽掉了等待I/O的时间如果是CPU密集型应用，则线程池大小设置为N+1；（对于计算密集型的任务，在拥有N个处理器的系统上，当线程池的大小为N+1时，通常能实现最优的效率。(即使当计算密集型的线程偶尔由于缺失故障或者其他原因而暂停时，这个额外的线程也能确保CPU的时钟周期不会被浪费。摘自《Java Concurrency In Practise》)

以下我们写一个cpu密集型的demo; 来试试不同线程数量的耗时结果

public class SrcTest {
    static int threadNum = 20;
    final static int taskNum = 200;
    static ExecutorService executorService = Executors.newFixedThreadPool(threadNum);
    static CountDownLatch endGate = new CountDownLatch(taskNum);


    public static void main(String[] args) throws InterruptedException {

        long start = System.currentTimeMillis();

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for&nbsp;(int&nbsp;i&nbsp;=&nbsp;0;&nbsp;i<&nbsp;taskNum;&nbsp;i++){
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;executorService.submit(cpuCal());
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endGate.await();
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;long&nbsp;end&nbsp;=&nbsp;System.currentTimeMillis();

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(&quot;线程池数量：&quot;+threadNum+&quot;&nbsp;CPU核数：&quot;+Runtime.getRuntime().availableProcessors()+&quot;全部结束:time:&quot;+(end-start));
&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;static&nbsp;Thread&nbsp;cpuCal(){
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;new&nbsp;Thread(()->{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;long&nbsp;start&nbsp;=&nbsp;System.currentTimeMillis();
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//随便写个cpu耗时的操作
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for&nbsp;(int&nbsp;i&nbsp;=&nbsp;0;i<10000000;i++){
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StringBuffer&nbsp;sb&nbsp;=&nbsp;new&nbsp;StringBuffer();
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sb.append(i).append(&quot;,&quot;);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;long&nbsp;end&nbsp;=&nbsp;System.currentTimeMillis();
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(&quot;线程ID:&quot;+Thread.currentThread().getId()+&quot;;&nbsp;消耗时间:&quot;+(end-start));
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endGate.countDown();
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;});
&nbsp;&nbsp;&nbsp;&nbsp;}
}



执行结果

threadNum=1

threadNum=2

threadNum=4

可以看到在线程数量为4的时候，我的这8核机器中的4个cpu飙升

threadNum=8

打开cpu使用率

可以看到在线程数量为8的时候，我的这8核机器中的8个cpu全部满负载运行

threadNum=14

threadNum=20

图标结果

实验系统配置情况:

物理cpu内核数：4 

sysctl hw.physicalcpu

逻辑cpu内核数：8 

sysctl hw.logicalcpu

因为开启了 超线程技术 就有了4核8线程

得出结论

通过上面的实验数据,我们分析可以得出在CPU密集型的场景下; 当线程数=CPU逻辑核数 的时候, 总体耗费的时间是最少的;并且 当线程数 越来越大的时候, 单任务平均耗时会越来越大，这是因为线程数越多，就会有越多的线程上下文切换，耗费一部分性能;当 线程数 > CPU逻辑核数时候, 总体耗费的时间已经不会有明显的减少，反而会略微上升,并且 单任务耗时确实逐渐增高的;

所以最终结论: 当CPU密集场景下; 线程数 =CPU逻辑核数时候, 总体效率最高;

当然了我们一般可以设置为 CPU逻辑核数+1 ; 这个1 的原因是：即使当计算密集型的线程偶尔由于缺失故障或者其他原因而暂停时，这个额外的线程也能确保CPU的时钟周期不会被浪费

IO密集型

如果是IO密集型应用，则线程池大小设置为2N+1

如果一台服务器上只部署这一个应用并且只有这一个线程池，那么这种估算或许合理，具体还需自行测试验证。

接下来在这个文档：服务器性能IO优化 中发现一个估算公式：

最佳线程数目 = （（线程等待时间+线程CPU时间）/线程CPU时间 ）* CPU数目进一步转换最佳线程数目 = （线程等待时间与线程CPU时间之比 + 1）* CPU数目

可以得出一个结论：

线程等待时间所占比例越高，需要越多线程。线程CPU时间所占比例越高，需要越少线程

实验(略)

混合型

混合型任务 可以将任务分成IO密集型和CPU密集型任务，然后分别用不同的线程池去处理。 只要分完之后两个任务的执行时间相差不大，那么就会比串行执行来的高效。 因为如果划分之后两个任务执行时间相差甚远，那么先执行完的任务就要等后执行完的任务，最终的时间仍然取决于后执行完的任务，而且还要加上任务拆分与合并的开销，得不偿失。

为什么线程上下文切换的时候会耗费性能

上下文切换的概念

先来解释一下什么是上下文切换(context switch)。在多任务处理系统中，作业数通常大于CPU数。为了让用户觉得这些任务在同时进行，CPU给每个任务分配一定时间，把当前任务状态保存下来，当前运行任务转为就绪（或者挂起、删除）状态，另一个被选定的就绪任务成为当前任务。之后CPU可以回过头再处理之前被挂起任务。上下文切换就是这样一个过程，它允许CPU记录并恢复各种正在运行程序的状态，使它能够完成切换操作。在这个过程中，CPU会停止处理当前运行的程序，并保存当前程序运行的具体位置以便之后继续运行

上下文切换带来的损耗

上下文切换会导致CPU在寄存器和运行队列之间来回奔波。这种消耗可以分为两种

参考文档

什么是CPU密集型、IO密集型？

并发下线程池的最佳数量计算

如何合理地估算线程池大小？