在 JVM 的调优实战中线程池的合理使用是提升性能的关键一环。线程池就像是一个高效的任务调度中心能够帮助我们更好地管理和利用系统资源。然而如果线程池的参数配置不合理就可能导致系统性能下降甚至出现各种问题。那么如何合理配置线程池参数呢这就是我们这一小节要重点探讨的内容。接下来我们将先了解线程池的工作原理再详细介绍线程池参数的配置方法最后结合实际案例给出调优方案。线程池的工作原理线程池的工作原理可以用一个形象的比喻来理解。想象有一个工厂这个工厂就是线程池工厂里的工人就是线程而生产任务就是我们要执行的任务。当有新的任务到来时工厂会根据自身的情况来决定如何处理这个任务。任务提交当我们向线程池提交一个任务时就相当于有一个新的生产任务被送到了工厂。线程池会首先检查当前正在工作的线程数量是否小于核心线程数。核心线程数就好比工厂里的正式员工数量这些员工是长期稳定在工厂工作的。如果当前工作的线程数量小于核心线程数线程池就会创建一个新的线程来处理这个任务就像工厂新招了一个正式员工来完成这个生产任务。例如我们创建了一个核心线程数为 5 的线程池当第一个任务提交时线程池会创建一个新的线程来执行这个任务。任务缓存如果当前工作的线程数量已经达到了核心线程数那么新提交的任务就会被放入任务队列中等待处理。任务队列就像是工厂的仓库用来存放暂时无法处理的生产任务。比如当有 6 个任务提交到核心线程数为 5 的线程池时前 5 个任务会分别由 5 个核心线程处理而第 6 个任务就会被放入任务队列中等待。创建新线程如果任务队列已经满了而此时又有新的任务提交线程池会检查当前线程数量是否小于最大线程数。最大线程数就好比工厂里最多能容纳的员工数量包括正式员工和临时工。如果小于最大线程数线程池就会创建一个新的线程来处理这个任务就像工厂临时招了一个临时工来完成这个生产任务。假设任务队列的容量为 10当有 16 个任务提交到核心线程数为 5、最大线程数为 20 的线程池时前 5 个任务由核心线程处理接下来 10 个任务放入任务队列当第 16 个任务提交时由于任务队列已满线程池会创建一个新的线程来处理这个任务。任务拒绝如果当前线程数量已经达到了最大线程数并且任务队列也已经满了那么新提交的任务就会被拒绝处理。线程池会根据设置的拒绝策略来处理被拒绝的任务。拒绝策略就好比工厂对于无法处理的生产任务的处理方式。例如当有 21 个任务提交到核心线程数为 5、最大线程数为 20、任务队列容量为 10 的线程池时前 5 个任务由核心线程处理10 个任务放入任务队列5 个任务由额外创建的线程处理当第 21 个任务提交时由于线程数量已达到最大线程数且任务队列已满这个任务就会被拒绝处理。线程池参数配置线程池有多个重要的参数这些参数的合理配置直接影响着线程池的性能和行为。下面我们来详细介绍这些参数。核心线程数corePoolSize核心线程数是线程池长期保持运行的线程数量。当有新任务提交时线程池会优先使用核心线程来处理任务。核心线程数的设置需要根据应用的特点和系统资源来决定。如果应用是 CPU 密集型的即应用主要进行大量的计算任务那么核心线程数可以设置为 CPU 核心数 1。这是因为 CPU 密集型任务需要大量的 CPU 资源过多的线程会导致线程上下文切换频繁降低性能。例如一台服务器的 CPU 核心数为 8那么核心线程数可以设置为 9。如果应用是 IO 密集型的即应用主要进行大量的输入输出操作如数据库读写、网络请求等那么核心线程数可以设置得大一些一般可以设置为 CPU 核心数 * 2。这是因为 IO 密集型任务在进行 IO 操作时CPU 处于空闲状态此时可以利用更多的线程来提高系统的并发处理能力。例如同样是 CPU 核心数为 8 的服务器对于 IO 密集型应用核心线程数可以设置为 16。最大线程数maximumPoolSize最大线程数是线程池允许创建的最大线程数量。当任务队列已满且核心线程都在工作时线程池会创建新的线程直到达到最大线程数。最大线程数的设置需要考虑系统的资源限制避免创建过多的线程导致系统资源耗尽。一般来说最大线程数可以根据系统的内存、CPU 等资源情况来设置。例如如果系统内存有限那么最大线程数就不能设置得过大否则会导致内存溢出。任务队列workQueue任务队列用于存储等待处理的任务。常见的任务队列有以下几种ArrayBlockingQueue这是一个有界队列队列的容量在创建时就需要指定。当任务数量超过队列容量时新的任务会根据线程池的策略进行处理。例如我们可以创建一个容量为 100 的 ArrayBlockingQueue。LinkedBlockingQueue这是一个无界队列理论上可以存储无限数量的任务。当使用 LinkedBlockingQueue 时最大线程数参数就会失效因为任务会一直放入队列中不会创建额外的线程。例如在一些对任务处理顺序有严格要求的场景中可以使用 LinkedBlockingQueue。SynchronousQueue这是一个特殊的队列它不存储任务每个插入操作必须等待另一个线程的移除操作反之亦然。使用 SynchronousQueue 时线程池会优先创建新的线程来处理任务而不是将任务放入队列。例如在一些对任务处理速度要求很高的场景中可以使用 SynchronousQueue。线程空闲时间keepAliveTime线程空闲时间是当线程池中的线程数量超过核心线程数时多余的空闲线程在被销毁之前等待新任务的时间。当一个线程在空闲时间内没有接到新的任务它就会被销毁。线程空闲时间的设置可以帮助我们合理利用系统资源避免创建过多的空闲线程。例如我们可以将线程空闲时间设置为 60 秒当一个线程在 60 秒内没有接到新的任务它就会被销毁。拒绝策略RejectedExecutionHandler当任务队列已满且线程数量达到最大线程数时新提交的任务会被拒绝处理。线程池提供了几种不同的拒绝策略AbortPolicy这是默认的拒绝策略当任务被拒绝时会抛出 RejectedExecutionException 异常。例如在一些对任务处理要求严格的场景中如果任务被拒绝系统需要及时处理这个异常。CallerRunsPolicy当任务被拒绝时会由提交任务的线程来执行这个任务。例如在一些对任务处理时间要求不高的场景中可以使用 CallerRunsPolicy这样可以避免任务丢失。DiscardPolicy当任务被拒绝时会直接丢弃这个任务不会抛出任何异常。例如在一些对任务处理结果要求不高的场景中可以使用 DiscardPolicy。DiscardOldestPolicy当任务被拒绝时会丢弃任务队列中最老的任务然后尝试将新任务放入队列中。例如在一些对任务处理顺序要求不高的场景中可以使用 DiscardOldestPolicy。调优方案及案例说明下面我们通过一个实际案例来介绍线程池参数的调优方案。假设我们有一个电商系统该系统需要处理大量的用户订单请求。在系统上线初期我们使用了默认的线程池配置但是发现系统在高并发情况下性能下降明显经常出现请求处理缓慢甚至超时的情况。经过分析我们发现是线程池参数配置不合理导致的。问题分析通过监控系统我们发现在高并发情况下任务队列经常被填满而线程池的最大线程数设置得比较小导致很多任务被拒绝处理。同时核心线程数设置也不合理没有根据系统的实际情况进行调整。调优方案核心线程数调整由于电商系统是 IO 密集型应用主要进行数据库读写、网络请求等操作我们根据服务器的 CPU 核心数将核心线程数从原来的 5 调整为 16。最大线程数调整考虑到系统的资源情况我们将最大线程数从原来的 10 调整为 32以应对高并发情况下的任务处理。任务队列调整原来使用的是 LinkedBlockingQueue由于它是无界队列导致任务会一直积压在队列中我们将其改为 ArrayBlockingQueue队列容量设置为 200。这样可以避免任务无限积压当队列满时会根据线程池的策略进行处理。拒绝策略调整将拒绝策略从默认的 AbortPolicy 调整为 CallerRunsPolicy这样当任务被拒绝时会由提交任务的线程来执行这个任务避免任务丢失。调优效果经过调优后系统在高并发情况下的性能得到了显著提升。请求处理速度明显加快任务拒绝率大幅降低系统的稳定性和可靠性也得到了提高。通过这个案例我们可以看到合理配置线程池参数对于系统性能的重要性。在实际应用中我们需要根据系统的特点和需求不断调整线程池参数以达到最佳的性能表现。总结与展望掌握了线程池参数的合理配置方法以及调优方案后我们能够根据应用的需求来合理配置线程池参数解决线程池参数配置不合理导致的性能问题从而提升 JVM 中线程的使用效率。这对于我们进行 JVM 调优实战是非常重要的一步。掌握了线程池参数配置内容后下一节我们将深入学习锁优化实践进一步完善对本章 JVM 中线程和锁优化主题的认知。 系列专栏导航 《JVM调优》 博客概览《程序员技术成长导航专栏汇总》