【线程池进阶】线程池性能提升之道：核心线程数选择与定制实战

大家好，我是Coder哥，今天我们来聊一下Java线程池的创建技巧与原则，我们知道在使用线程池的时候一般不用系统创建的，系统创建的可能会存在风险【为什么不应该自动创建线程池？】那么如果我们自己创建，到底应该如何创建才能充分并合理地使用 CPU 和内存等资源，从而最大限度地提高程序的性能呢？

事实上，在实际工作中，我们需要根据任务类型的不同选择对应的策略。

核心线程数如何选择？

其实在实际的业务中，我们的任务总体上分两类，一类是耗CPU型的，另一类是耗时IO型的，对于这两类的业务，线程数量设置也各不相同

CPU 密集型任务

首先，对于CPU 密集型任务，比如计算、压缩、加密、解密等需要耗费大量CPU 资源的任务。对于这样的任务最佳的线程数一般为 CPU 核心数的 1到2 倍，如果设置过多的线程数，效果并不好。为什么这么说呢？比如我们设置的线程数量是 CPU 核心数的 2 倍以上，这时计算任务会占用大量的 CPU 资源，所以这时 CPU 的每个核心基本都是满负荷的，而我们又设置了过多的线程，每个线程都想去利用 CPU ，这样就会造成不必要的上下文切换，此时线程数的增多并没有让性能提升，反而由于线程数量过多而带来的上下文切换进而导致性能下降。

对于这样的情况，我们最好还要同时考虑在同一机器上有哪些会占用过多 CPU 资源的程序在运行，然后对资源使用做整体的平衡。

耗时 IO 型任务

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

《Java并发编程实战》(电子书地址:https://todocoder.com/pdf/java/002004.html)的作者 Brain Goetz 推荐的计算方法：

线程数 = CPU 核心数 *（1+平均等待时间/平均工作时间）

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

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

结论

综上所述我们就可以得出一个结论：

线程的平均工作时间所占比例越高，就需要越少的线程；
线程的平均等待时间所占比例越高，就需要越多的线程；
针对不同的程序，进行对应的实际测试就可以得到最合适的选择。

如何根据实际需要，定制自己的线程池？

上面我们说了不同类型任务核心线程数量应该怎么选择，那么在具体业务中，我们要考虑的参数 【线程池的各个参数的含义及线程池创建流程】 有很多，那么如何根据实际需要，定制自己的线程池呢？

核心线程数

上面我们说过，合理的线程数量和任务类型，以及 CPU 核心数都有关系，基本结论是线程的平均工作时间所占比例越高，就需要越少的线程；线程的平均等待时间所占比例越高，就需要越多的线程。而对于最大线程数而言，如果我们执行的任务类型不是固定的，比如一段时间是 CPU 密集型，另一段时间是 IO 密集型，或是同时有两种任务相互混搭。那么在这种情况下，我们可以把最大线程数设置成核心线程数的几倍，以便应对任务突发情况。当然更好的办法是用不同的线程池执行不同类型的任务，让任务按照类型区分开，而不是混杂在一起，这样就可以按照上一课时估算的线程数或经过压测得到的结果来设置合理的线程数了，达到更好的性能。

阻塞队列

对于阻塞队列这个参数而言，我们可以选择之前介绍过的 【 6种常见的线程池及Java8的ForkJoinPool介绍】 LinkedBlockingQueue 或者 SynchronousQueue 或者 DelayedWorkQueue，不过还有一种常用的阻塞队列叫 ArrayBlockingQueue，它也经常被用于线程池中，这种阻塞队列内部是用数组实现的，在新建对象的时候要求传入容量值，且后期不能扩容，所以 ArrayBlockingQueue 的最大的特点就是容量是有限的。这样一来，如果任务队列放满了任务，而且线程数也已经达到了最大值，线程池根据规则就会拒绝新提交的任务，这样一来就可能会产生一定的数据丢失。

但相比于无限增加任务或者线程数导致内存不足，进而导致程序崩溃，数据丢失还是要更好一些的，如果我们使用了 ArrayBlockingQueue 这种阻塞队列，再加上我们限制了最大线程数量，就可以非常有效地防止资源耗尽的情况发生。此时的队列容量大小和 maxPoolSize 是一个 trade-off，如果我们使用容量更大的队列和更小的最大线程数，就可以减少上下文切换带来的开销，但也可能因此降低整体的吞吐量；如果我们的任务是 IO 密集型，则可以选择稍小容量的队列和更大的最大线程数，这样整体的效率就会更高，不过也会带来更多的上下文切换。

线程工厂

对于线程工厂 threadFactory 这个参数，我们可以使用默认的 defaultThreadFactory，也可以传入自定义的有额外能力的线程工厂，因为我们可能有多个线程池，而不同的线程池之间有必要通过不同的名字来进行区分，所以可以传入能根据业务信息进行命名的线程工厂，以便后续可以根据线程名区分不同的业务进而快速定位问题代码。比如可以通过com.google.common.util.concurrent.ThreadFactory

Builder 来实现，如代码所示。

ThreadFactoryBuilder builder = new ThreadFactoryBuilder();
ThreadFactory rpcFactory = builder.setNameFormat("rpc-pool-%d").build();

我们生成了名字为 rpcFactory 的 ThreadFactory，它的 nameFormat 为 “rpc-pool-%d” ，那么它生成的线程的名字是有固定格式的，它生成的线程的名字分别为”rpc-pool-1″，”rpc-pool-2″ ，以此类推。

拒绝策略

最后一个参数是拒绝策略，我们可以根据业务需要，选择第 11 讲里的四种拒绝策略之一来使用：AbortPolicy，DiscardPolicy，DiscardOldestPolicy 或者 CallerRunsPolicy。除此之外，我们还可以通过实现 RejectedExecutionHandler 接口来实现自己的拒绝策略，在接口中我们需要实现 rejectedExecution 方法，在 rejectedExecution 方法中，执行例如打印日志、暂存任务、重新执行等自定义的拒绝策略，以便满足业务需求。如代码所示。

private static class CustomRejectionHandler implements RejectedExecutionHandler { 
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { 
        //打印日志、暂存任务、重新执行等拒绝策略
    } 
}

总结

所以定制自己的线程池和我们的业务是强相关的，首先我们需要掌握每个参数的含义，以及常见的选项，然后根据实际需要，比如说并发量、内存大小、是否接受任务被拒绝等一系列因素去定制一个非常适合自己业务的线程池，这样既不会导致内存不足，同时又可以用合适数量的线程来保障任务执行的效率，并在拒绝任务时有所记录方便日后进行追溯。