JAVA线程池如何调优

在JAVA中，线程可以使用定制的代码来管理，应用也可以利用线程池。在使用线程池时，有一个因素非常关键：调节线程池的大小对获得最好的性能至关重要。线程池的性能会随线程池大小这一基本选择而有所不同，在某些条件下，线程池过大对性能也有很多不利的影响。

所有线程池的工作方式本质是一样的：有一个任务队列，一定数量的线程会从该任务队列获取任务然后执行。任务的结果可以发回客户端，或保存到数据库，或保存到某个内部数据结构中，等等。但是在执行完任务后，这个线程会返回任务队列，检索另一个任务并执行。

线程池有最小线程数和最大线程数。池中会有最小数目的线程随时待命，等待任务指派给它们。因为创建线程的成本非常高昂，这样可以提高任务提交时的整体性能。线程池的最小线程数称作核心池大小，考虑ThreadPoolExecutor最简单的情况，如果有个任务要执行，而所有的并发线程都在忙于执行另一个任务，就会启动一个新线程，直到创建的线程达到最大线程数。

一般我们会从以下几个方面对线程池进行设置：

设置最大线程数

对于给定硬件上的给定负载，最大线程数设置为多少最好呢？这个问题回答起来并不简单：它取决于负载特性以及底层硬件。特别是，最优线程数还与每个任务阻塞的频率有关。

假设JVM有4个CPU可用，很明显最大线程数至少要设置为4。的确，除了处理这些任务，JVM还有些线程要做其他的事，但是它们几乎从来不会占用一个完整的CPU，至于这个数值是否要大于4，则需要进行大量充分的测试。

有以下两点需要注意：

一旦服务器成为瓶颈，向服务器增加负载时非常有害的；

对于CPU密集型或IO密集型的机器增加线程数实际会降低整体的吞吐量；

设置最小线程数

一旦确定了线程池的最大线程数，就该确定所需的最小线程数了。大部分情况下，开发者会直截了当的将他们设置成同一个值。

将最小线程数设置为其他某个值（比如1），出发点是为了防止系统创建太多线程，以节省系统资源。指定一个最小线程数的负面影响相当小。如果第一次就有很多任务要执行，会有负面影响：这是线程池需要创建一个新线程。创建线程对性能不利，这也是为什么起初需要线程池的原因。

一般而言，对于线程数为最小值的线程池，一个新线程一旦创建出来，至少应该保留几分钟，以处理任何负载飙升。空闲时间应该以分钟计，而且至少在10分钟到30分钟之间，这样可以防止频繁创建线程。

线程池任务大小

等待线程池来执行的任务会被保存到某个队列或列表中；当池中有线程可以执行任务时，就从队列中拉出一个。这会导致不均衡：队列中任务的数量可能变得非常大。如果队列太大，其中的任务就必须等待很长时间，直到前面的任务执行完毕。

对于任务队列，线程池通常会限制其大小。但是这个值应该如何调优，并没有一个通用的规则。若要确定哪个值能带来我们需要的性能，测量我们的真实应用是唯一的途径。不管是哪种情况，如果达到了队列限制，再添加任务就会失败。ThreadPoolExecutor有一个rejectedExecution方法，用于处理这种情况，默认会抛出RejectedExecutionExecption。应用服务器会向用户返回某个错误：或者是HTTP状态码500，或者是Web服务器捕获异常错误，并向用户给出合理的解释消息—其中后者是最理想的。

设置ThreadPoolExecutor的大小

线程池的一般行为是这样的：创建时准备最小数目的线程，如果来了一个任务，而此时所有的线程都在忙碌，则启动一个新线程（一直到达到最大线程数），任务就会立即执行。否则，任务被加入到等待队列，如果队列中已经无法加入新任务，则拒接之。

根据所选任务队列的类型，ThreadPoolExecutor会决定何时会启动一个新线程。有以下三种可能：

SynchronousQueue

如果ThreadPoolExecutor搭配的是SynchronousQueue，则线程池的行为和我们预期的一样，它会考虑线程数：如果所有的线程都在忙碌，而且池中的线程数尚未达到最大，则会为新任务启动一个新线程。然而这个队列没办法保存等待的任务：如果来了一个任务，创建的线程数已经达到最大值，而且所有的线程都在忙碌，则新的任务都会被拒绝，所以如果是管理少量的任务，这是个不错的选择，对于其他的情况就不适合了。

无界队列

如果ThreadPoolExecutor搭配的是无界队列，如LinkedBlockingQueue，则不会拒绝任何任务（因为队列大小没有限制）。这种情况下，ThreadPoolExecutor最多仅会按照最小线程数创建线程，也就是说最大线程池大小被忽略了。如果最大线程数和最小线程数相同，则这种选择和配置了固定线程数的传统线程池运行机制最为接近。

有界队列

搭配了有界队列，如ArrayBlockingQueue的ThreadPoolExecutor会采用一个非常负责的算法。比如假定线程池的最小线程数为4，最大为8所用的ArrayBlockingQueue最大为10。随着任务到达并被放到队列中，线程池中最多运行4个线程（即最小线程数）。即使队列完全填满，也就是说有10个处于等待状态的任务，ThreadPoolExecutor也只会利用4个线程。

如果队列已满，而又有新任务进来，此时才会启动一个新线程，这里不会因为队列已满而拒接该任务，相反会启动一个新线程。新线程会运行队列中的第一个任务，为新来的任务腾出空间。

这个算法背后的理念是：该池大部分时间仅使用核心线程（4个），即使有适量的任务在队列中等待运行。这时线程池就可以用作节流阀。如果挤压的请求变得非常多，这时该池就会尝试运行更多的线程来清理；这时第二个节流阀—最大线程数就起作用了。

对于上面提到的每一种选择，都能找到很多支持或反对的依据，但是在尝试获得最好的性能时，可以应用KISS原则"Keep it simple，stupid"。可以将最小线程数和最大线程数设置为相同，在保存任务方面，如果适合无界队列，则选择LinkedBlockingQueue；如果适合有界队列，则选择ArrayBlockingQueue。

小结：

有时对象池也是不错的选择，线程池就是情形之一：线程初始化的成本很高，线程池使得系统上的线程数容易控制。 线程池必须需仔细调优，盲目的向池中添加新线程，在某些情况下对性能会有不利的影响。 使用ThreadPoolExecutor时，选择更简单选项通常会带来最好的、最能预见的性能。

如果大家对java架构相关感兴趣，可以关注下面公众号，会持续更新java基础面试题, netty, spring boot,spring cloud等系列文章，一系列干货随时送达, 超神之路从此展开, BTAJ不再是梦想!

原文地址：https://blog.csdn.net/jinxinxin1314/article/details/108032978?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522168904449916800185828444%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=168904449916800185828444&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_v31_ecpm-16-108032978-null-null.142^v88^control_2,239^v2^insert_chatgpt&utm_term=java%E4%BC%98%E5%8C%96