如何设置高并和高可用场景的线程池的核心线程数

在业务驱动引擎中有这样一个场景，需要处理千万级别的数据的一个批处理算法去触发调度任务的执行，这个时候就需要使用多线程去处理。

 

多线程代码：

    /**
     * 共享线程池
     * @return
     */
    @Bean("threadPoolTaskExecutor")
    public ThreadPoolTaskExecutor threadPoolTaskExecutor() {
   
        ThreadPoolTaskExecutor threadPoolTaskExecutor = new ThreadPoolTaskExecutor();

        /* 核心线程数*/
        threadPoolTaskExecutor.setCorePoolSize(10);
        //最大线程数--当活跃线程数大于核心线程数时，空闲的多余线程最大存活时间
        threadPoolTaskExecutor.setMaxPoolSize(20);
        //队列最大长度 >= mainExecutor.maxSize
        threadPoolTaskExecutor.setQueueCapacity(500);
        threadPoolTaskExecutor.setThreadNamePrefix("event-driven-engine-task-step");
        //线程池维护线程所允许的空闲时间
        threadPoolTaskExecutor.setKeepAliveSeconds(60);
        //线程池对拒绝任务(无线程可用)的处理策略:调用者自己处理
        threadPoolTaskExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        threadPoolTaskExecutor.setThreadFactory(new ThreadFactoryBuilder().setNameFormat("event-driven-engine-task-step-thread-pool-%d").build());
        return threadPoolTaskExecutor;
    }

 

基于上述Spring-Batch批处理任务的多线程参数该如何配置比较合理呢？

线程数的设置的最主要的目的是为了充分并合理地使用 CPU 和内存等资源，从而最大限度地提高程序的性能，因此让我们一起去探索吧！

 

首先要考虑到 CPU 核心数，那么在 Java 中如何获取核心线程数？

可以使用如下方法来获取：

Runtime.getRuntime().availableProcessor()

 

在确认了核心数后，再去判断是 CPU 密集型任务还是 IO 密集型任务：

CPU 密集型任务：比如像加解密，压缩、计算等一系列需要大量耗费 CPU 资源的任务，大部分场景下都是纯 CPU 计算。IO 密集型任务：比如像 MySQL 数据库、文件的读写、网络通信等任务，这类任务不会特别消耗 CPU 资源，但是 IO 操作比较耗时，会占用比较多时间。

 

在知道如何判断任务的类别后，让我们分两个场景进行讨论：

CPU 密集型任务

对于 CPU 密集型计算，多线程本质上是提升多核 CPU 的利用率，所以对于一个 8 核的 CPU，每个核一个线程，理论上创建 8 个线程就可以了。

如果设置过多的线程数，实际上并不会起到很好的效果。此时假设我们设置的线程数量是 CPU 核心数的 2 倍，因为计算任务非常重，会占用大量的 CPU 资源，所以这时 CPU 的每个核心工作基本都是满负荷的，而我们又设置了过多的线程，每个线程都想去利用 CPU 资源来执行自己的任务，这就会造成不必要的上下文切换，此时线程数的增多并没有让性能提升，反而由于线程数量过多会导致性能下降。

因此，对于 CPU 密集型的计算场景，理论上线程的数量 = CPU 核数就是最合适的，不过通常把线程的数量设置为CPU 核数 +1，会实现最优的利用率。即使当密集型的线程由于偶尔的内存页失效或其他原因导致阻塞时，这个额外的线程也能确保 CPU 的时钟周期不会被浪费，从而保证 CPU 的利用率。

如下图就是在一个 8 核 CPU 的电脑上，通过修改线程数来测试对 CPU 密集型任务（素数计算）的性能影响。

可以看到线程数小于 8 时，性能是很差的，在线程数多于处理器核心数对性能的提升也很小，因此可以验证公式还是具有一定适用性的。

除此之外，我们最好还要同时考虑在同一台机器上还有哪些其他会占用过多 CPU 资源的程序在运行，然后对资源使用做整体的平衡。

 

IO 密集型任务

对于 IO 密集型任务最大线程数一般会大于 CPU 核心数很多倍，因为 IO 读写速度相比于 CPU 的速度而言是比较慢的，如果我们设置过少的线程数，就可能导致 CPU 资源的浪费。而如果我们设置更多的线程数，那么当一部分线程正在等待 IO 的时候，它们此时并不需要 CPU 来计算，那么另外的线程便可以利用 CPU 去执行其他的任务，互不影响，这样的话在任务队列中等待的任务就会减少，可以更好地利用资源。

对于 IO 密集型计算场景，最佳的线程数是与程序中 CPU 计算和 IO 操作的耗时比相关的，《Java并发编程实战》的作者 Brain Goetz 推荐的计算方法如下：

线程数 = CPU 核心数 * (1 + IO 耗时/ CPU 耗时)

通过这个公式，我们可以计算出一个合理的线程数量，如果任务的平均等待时间长，线程数就随之增加，而如果平均工作时间长，也就是对于我们上面的 CPU 密集型任务，线程数就随之减少。可以采用 APM 工具统计到每个方法的耗时，便于计算 IO 耗时和 CPU 耗时。

在这里引用Java并发编程实战中的图，方便大家更容易理解：

还有一派的计算方式是《Java虚拟机并发编程》中提出的：

线程数 = CPU 核心数 / (1 - 阻塞系数)

其中计算密集型阻塞系数为 0，IO 密集型阻塞系数接近 1，一般认为在 0.8 ~ 0.9 之间。比如 8 核 CPU，按照公式就是 2 / ( 1 - 0.9 ) = 20 个线程数

上图是 IO 密集型任务的一个测试，是在双核处理器上开不同的线程数（从 1 到 40）来测试对程序性能的影响，可以看到线程池数量达到 20 之后，曲线逐渐水平，说明开再多的线程对程序的性能提升也毫无帮助。

太少的线程数会使得程序整体性能降低，而过多的线程也会消耗内存等其他资源，所以如果想要更准确的话，可以进行压测，监控 JVM 的线程情况以及 CPU 的负载情况，根据实际情况衡量应该创建的线程数，合理并充分利用资源。

同时，有很多线程池的应用，比如 Tomcat、Redis、Jdbc 等，每个应用设置的线程数也是不同的，比如 Tomcat 为流量入口，那么线程数的设置可能就要比其他应用要大。

 

 

接下来我们进行一一分析：

1：高并发、任务执行时间短的业务，线程池线程数可以设置为CPU核数+1，减少线程上下文的切换

2：并发不高、任务执行时间长的业务这就需要区分开看了：

　　a）假如是业务时间长集中在IO操作上，也就是IO密集型的任务，因为IO操作并不占用CPU，所以不要让所有的CPU闲下来，可以适当加大线程池中的线程数目，让CPU处理更多的业务

　　b）假如是业务时间长集中在计算操作上，也就是计算密集型任务，这个就没办法了，线程池中的线程数设置得少一些，减少线程上下文的切换

           （其实从一二可以看出无论并发高不高，对于业务中是否是cpu密集还是I/O密集的判断都是需要的当前前提是你需要优化性能的前提下）

3：并发高、业务执行时间长，解决这种类型任务的关键不在于线程池而在于整体架构的设计，看看这些业务里面某些数据是否能做缓存是第一步，我们的项目使用的时redis作为缓存（这类非关系型数据库还是挺好的）。增加服务器是第二步（一般政府项目的首先，因为不用对项目技术做大改动，求一个稳，但前提是资金充足），至于线程池的设置，设置参考 2 。最后，业务执行时间长的问题，也可能需要分析一下，看看能不能使用中间件（任务时间过长的可以考虑拆分逻辑放入队列等操作）对任务进行拆分和解耦。

 

三.：总结：

　　01：一个计算为主的程序（CPU密集型程序），多线程跑的时候，可以充分利用起所有的 CPU 核心数，比如说 8 个核心的CPU ,开8 个线程的时候，可以同时跑 8 个线程的运算任务，此时是最大效率。但是如果线程远远超出 CPU 核心数量，反而会使得任务效率下降，因为频繁的切换线程也是要消耗时间的。因此对于 CPU 密集型的任务来说，线程数等于 CPU 数是最好的了。

　　02：如果是一个磁盘或网络为主的程序（IO密集型程序），一个线程处在 IO 等待的时候，另一个线程还可以在 CPU 里面跑，有时候 CPU 闲着没事干，所有的线程都在等着 IO，这时候他们就是同时的了，而单线程的话此时还是在一个一个等待的。我们都知道 IO 的速度比起 CPU 来是很慢的。此时线程数等于CPU核心数的两倍是最佳的。

      03：通过对线程数设置的探究，我们可以得知线程数的设置首先和 CPU 核心数有莫大关联，除此之外，我们需要根据任务类型的不同选择对应的策略，线程的平均工作时间所占比例越高，就需要越少的线程；线程的平均等待时间所占比例越高，就需要越多的线程；针对不同的程序，进行对应的实际测试就可以得到最合适的选择。