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

文章目录

CPU密集型

执行结果

图标结果

得出结论

IO密集型

实验(略)

混合型

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

上下文切换的概念

上下文切换带来的损耗

参考文档

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();
        for (int i = 0; i< taskNum; i++){
            executorService.submit(cpuCal());
        }
        endGate.await();
        long end = System.currentTimeMillis();
        System.out.println("线程池数量："+threadNum+" CPU核数："+Runtime.getRuntime().availableProcessors()+"全部结束:time:"+(end-start));
    }
    public static Thread cpuCal(){
        return new Thread(()->{
            long start = System.currentTimeMillis();
            //随便写个cpu耗时的操作
            for (int i = 0;i<10000000;i++){
                StringBuffer sb = new StringBuffer();
                sb.append(i).append(",");
            }
            long end = System.currentTimeMillis();
            System.out.println("线程ID:"+Thread.currentThread().getId()+"; 消耗时间:"+(end-start));
            endGate.countDown();
        });
    }
}

执行结果

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线程

线程数 全部结束耗费时间 单任务平均耗费时间

1 63007 320

2 35828 345

4 24252 430

8 21340 700

14 22837 1100

20 22081 1920

得出结论

通过上面的实验数据,我们分析可以得出

在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寄存器需要保存和加载, 系统调度器的代码需要执行, TLB实例需要重新加载, CPU 的pipeline需要刷掉

间接损耗 多核的cache之间得共享数据