线程池详解

今天是2025/03/29 15:36 

最近阅读了美团关于线程池的技术文章，感觉大佬的知识深度和我们确实不一样，在这里做一个总结，相当于番外篇了

Java线程池实现原理及其在美团业务中的实践 - 美团技术团队

1.线程池介绍

ThreadPoolExecutor

线程池的好处：

• 降低资源消耗：通过池化技术重复利用已创建的线程，降低线程创建和销毁造成的损耗。

• 提高响应速度：任务到达时，无需等待线程创建即可立即执行。

• 提高线程的可管理性：线程是稀缺资源，如果无限制创建，不仅会消耗系统资源，还会因为线程的不合理分布导致资源调度失衡，降低系统的稳定性。使用线程池可以进行统一的分配、调优和监控。

• 提供更多更强大的功能：线程池具备可拓展性，允许开发人员向其中增加更多的功能。比如延时定时线程池ScheduledThreadPoolExecutor，就允许任务延期执行或定期执行。

线程池是做什么的：解决资源管理问题

1. 频繁申请/销毁资源和调度资源，将带来额外的消耗，可能会非常巨大。

2. 对资源无限申请缺少抑制手段，易引发系统资源耗尽的风险。

3. 系统无法合理管理内部的资源分布，会降低系统的稳定性。

2.核心设计与实现

2.1 Executor

顶层接口Executor提供了一种思想：将任务提交和任务执行进行解耦

ExecutorService接口增加了一些能力：

（1）扩充执行任务的能力，补充可以为一个或一批异步任务生成Future的方法；

（2）提供了管控线程池的方法，比如停止线程池的运行。

AbstractExecutorService则是上层的抽象类，将执行任务的流程串联了起来，保证下层的实现只需关注一个执行任务的方法即可。

实现类ThreadPoolExecutor实现最复杂的运行部分，ThreadPoolExecutor将会一方面维护自身的生命周期，另一方面同时管理线程和任务，使两者良好的结合从而执行并行任务。

线程池的执行流程

线程池内部维护了生产者-消费者模型

任务管理-线程管理

其中任务管理是生产者，线程管理是消费者

当任务提交后，线程池会判断该任务后续的流转：

（1）直接申请线程执行该任务；

（2）缓冲到队列中等待线程执行；

（3）拒绝该任务。线程管理部分是消费者，

2.2 生命周期管理

线程的内部管理

1. 线程池如何维护自身状态。

2. 线程池如何管理任务。

3. 线程池如何管理线程。

线程池维护自身状态

线程池运行的状态：使用一个变量维护两个值：运行状态(runState)和线程数量 (workerCount)。

private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));

ctl这个AtomicInteger类型，是对线程池的运行状态和线程池中有效线程的数量进行控制的一个字段

高3位保存runState，低29位保存workerCount，两个变量之间互不干扰。

private static int runStateOf(int c)     { return c & ~CAPACITY; } //计算当前运行状态
private static int workerCountOf(int c)  { return c & CAPACITY; }  //计算当前线程数量
private static int ctlOf(int rs, int wc) { return rs | wc; }   //通过状态和线程数生成ctl

好处：

1. 原子性与一致性

   CAS同步维护内部数据，线程安全。

   如果runState和workerCount作为独立变量，修改时需额外同步，而合并后仅需操作一个原子变量，简化了并发控制。

2. 高效的位运算 运算速率快

3. 空间优化 占用空间少

4. 设计合理性 3位能表示8个状态 running shutdown stop tidying terminated位数合适

2.3 线程池管理任务

2.3.1 任务调度

任务调度是线程池的主要入口，当用户提交了一个任务，接下来这个任务将如何执行都是由这个阶段决定的。了解这部分就相当于了解了线程池的核心运行机制。

首先，所有任务的调度都是由execute方法完成的，这部分完成的工作是：

检查现在线程池的运行状态、运行线程数、运行策略，决定接下来执行的流程，是直接申请线程执行，或是缓冲到队列中执行，亦或是直接拒绝该任务。其执行过程如下：

1. 首先检测线程池运行状态，如果不是RUNNING，则直接拒绝，线程池要保证在RUNNING的状态下执行任务。

2. 如果workerCount < corePoolSize，则创建并启动一个线程来执行新提交的任务。

3. 如果workerCount >= corePoolSize，且线程池内的阻塞队列未满，则将任务添加到该阻塞队列中。

4. 如果workerCount >= corePoolSize && workerCount < maximumPoolSize，且线程池内的阻塞队列已满，则创建并启动一个线程来执行新提交的任务。

5. 如果workerCount >= maximumPoolSize，并且线程池内的阻塞队列已满, 则根据拒绝策略来处理该任务, 默认的处理方式是直接抛异常。

2.3.2 任务缓冲

任务缓冲模块是线程池能够管理任务的核心部分。线程池的本质是对任务和线程的管理，而做到这一点最关键的思想就是将任务和线程两者解耦，不让两者直接关联，才可以做后续的分配工作。线程池中是以生产者消费者模式，通过一个阻塞队列来实现的。阻塞队列缓存任务，工作线程从阻塞队列中获取任务。

2.3.3 任务申请

getTask这部分进行了多次判断，为的是控制线程的数量，使其符合线程池的状态。如果线程池现在不应该持有那么多线程，则会返回null值。工作线程Worker会不断接收新任务去执行，而当工作线程Worker接收不到任务的时候，就会开始被回收。

2.3.4 任务拒绝

public interface RejectedExecutionHandler {
    void rejectedExecution(Runnable r, ThreadPoolExecutor executor);
}

丢弃任务抛异常，丢弃任务不抛异常，丢弃最早的任务，由调用线程处理该任务

2.4 线程池Worker线程管理

2.4.1 Worker线程

线程池为了掌握线程的状态并维护线程的生命周期，设计了线程池内的工作线程Worker。

其实线程池的核心线程 非核心线程 都是worker类，里面封装了 Thread和Runnable的fisrtTask

private final class Worker extends AbstractQueuedSynchronizer implements Runnable{
    final Thread thread;//Worker持有的线程
    Runnable firstTask;//初始化的任务，可以为null
}

线程池需要管理线程的生命周期，需要在线程长时间不运行的时候进行回收。线程池使用一张Hash表去持有线程的引用，这样可以通过添加引用、移除引用这样的操作来控制线程的生命周期。这个时候重要的就是如何判断线程是否在运行。

我们可以用餐厅服务员的工作模式来类比理解线程池的这套机制：

1. 餐厅经理（线程池）的登记表（Hash表）

   • 每个服务员（Worker线程）上岗时要在登记表按手印（添加引用）

   • 下班时要擦掉手印（移除引用）

   • 经理通过登记表知道哪些服务员在岗

2. 服务员的工作围裙（AQS锁）

   • 每个服务员都有一件特殊围裙：

   • 围裙只有1个扣子（不可重入）

   • 穿上围裙 = 扣上扣子（获取锁）

   • 脱掉围裙 = 解开扣子（释放锁）

3. 工作状态判断规则

   • 当服务员：

   • ✅ 穿着围裙（持有锁） → 正在端菜（执行任务） → 不可打断

   • ❌ 没穿围裙（未持锁） → 在休息区待命（空闲） → 可打断

4. 打烊时的处理（shutdown） 经理要下班时：

   • 悄悄去碰每个服务员的围裙扣子（tryLock）

   • 如果扣子一碰就开（获取锁成功）→ 说明服务员在发呆 → 可以安全劝退

   • 如果扣子解不开（获取锁失败）→ 服务员正在端最后一道菜 → 等他自然下班

关键设计亮点：

• 用单扣围裙（不可重入锁）而不是魔术贴围裙（可重入锁），是为了避免：

  • 服务员端汤时（获得锁）

  • 中途又拿调料（重入锁）

  • 导致经理误以为他还在工作，其实已经完成主要任务

现实案例： 当某服务员：

1. 接到送牛排任务 → 穿围裙（lock）

2. 送餐途中发现没刀叉 → 想重穿围裙拿餐具（重入）

3. 但单扣围裙设计让他发现：自己已经穿着围裙了！

4. 于是必须先送回牛排（释放锁）才能拿餐具

5. 这样经理始终能准确判断他的真实状态

这套设计确保了：

• 精准判断线程状态（看围裙穿着情况）

• 安全回收资源（只打断发呆的服务员）

• 避免任务执行被意外中断（保护穿围裙的工作者）

2.4.2 Worker线程增加

增加线程是通过线程池中的addWorker方法，该方法的功能就是增加一个线程，该方法不考虑线程池是在哪个阶段增加的该线程，这个分配线程的策略是在上个步骤完成的，该步骤仅仅完成增加线程，并使它运行，最后返回是否成功这个结果。

addWorker方法有两个参数：firstTask、core。firstTask参数用于指定新增的线程执行的第一个任务，该参数可以为空；core参数为true表示在新增线程时会判断当前活动线程数是否少于corePoolSize，false表示新增线程前需要判断当前活动线程数是否少于maximumPoolSize

说人话就是 core为true就创建核心线程，false就非核心或阻塞队列

2.4.3 Worker线程回收

线程池中线程的销毁依赖JVM自动的回收

try {
  while (task != null || (task = getTask()) != null) {
    //执行任务
  }
} finally {
  processWorkerExit(w, completedAbruptly);//获取不到任务时，主动回收自己
}

2.4.4 Worker线程执行任务

在Worker类中的run方法调用了runWorker方法来执行任务，runWorker方法的执行过程如下：

1.while循环不断地通过getTask()方法获取任务。

2.getTask()方法从阻塞队列中取任务。

3.如果线程池正在停止，那么要保证当前线程是中断状态，否则要保证当前线程不是中断状态。

线程需要不断感知 中断信号

4.执行任务。

5.如果getTask结果为null则跳出循环，执行processWorkerExit()方法，销毁线程。

3、线程池在业务中的实践

3.1 业务背景

场景1：快速响应用户请求

描述：用户发起的实时请求，服务追求响应时间。比如说用户要查看一个商品的信息，那么我们需要将商品维度的一系列信息如商品的价格、优惠、库存、图片等等聚合起来，展示给用户。

分析：从用户体验角度看，这个结果响应的越快越好，如果一个页面半天都刷不出，用户可能就放弃查看这个商品了。而面向用户的功能聚合通常非常复杂，伴随着调用与调用之间的级联、多级级联等情况，业务开发同学往往会选择使用线程池这种简单的方式，将调用封装成任务并行的执行，缩短总体响应时间。另外，使用线程池也是有考量的，这种场景最重要的就是获取最大的响应速度去满足用户，所以应该不设置队列去缓冲并发任务，调高corePoolSize和maxPoolSize去尽可能创造多的线程快速执行任务。

场景2：快速处理批量任务

描述：离线的大量计算任务，需要快速执行。比如说，统计某个报表，需要计算出全国各个门店中有哪些商品有某种属性，用于后续营销策略的分析，那么我们需要查询全国所有门店中的所有商品，并且记录具有某属性的商品，然后快速生成报表。

分析：这种场景需要执行大量的任务，我们也会希望任务执行的越快越好。这种情况下，也应该使用多线程策略，并行计算。但与响应速度优先的场景区别在于，这类场景任务量巨大，并不需要瞬时的完成，而是关注如何使用有限的资源，尽可能在单位时间内处理更多的任务，也就是吞吐量优先的问题。所以应该设置队列去缓冲并发任务，调整合适的corePoolSize去设置处理任务的线程数。在这里，设置的线程数过多可能还会引发线程上下文切换频繁的问题，也会降低处理任务的速度，降低吞吐量。

3.2 实际问题及方案思考

3.2.1 线程池配置问题

Case1：2018年XX页面展示接口大量调用降级：

事故描述：XX页面展示接口产生大量调用降级，数量级在几十到上百。

事故原因：该服务展示接口内部逻辑使用线程池做并行计算，由于没有预估好调用的流量，导致最大核心数设置偏小，大量抛出RejectedExecutionException，触发接口降级条件，示意图如下：

Case2：2018年XX业务服务不可用S2级故障

事故描述：XX业务提供的服务执行时间过长，作为上游服务整体超时，大量下游服务调用失败。

事故原因：该服务处理请求内部逻辑使用线程池做资源隔离，由于队列设置过长，最大线程数设置失效，导致请求数量增加时，大量任务堆积在队列中，任务执行时间过长，最终导致下游服务的大量调用超时失败。示意图如下：

---

Disruptor vs Actor vs 协程 vs 线程池

####

维度	Disruptor	Actor模型	协程	线程池
基本单元	事件(Event)	Actor（独立实体+消息邮箱）	协程（轻量级用户态线程）	线程（内核态线程）
通信方式	环形缓冲区（无锁）	异步消息传递	同步/异步代码调度	共享内存+锁
并发模型	单写多读/多写多读	完全隔离的分布式模型	协作式多任务	抢占式多线程
性能特点	纳秒级延迟，百万级TPS	高吞吐（微秒级延迟）	高并发（万级协程/线程）	千级线程/进程
典型应用场景	高频交易、日志处理	分布式系统、实时聊天	Web服务、I/O密集型任务	通用并发任务
资源消耗	极低（无锁设计）	中等（每个Actor约1MB内存）	极低（协程栈约KB级）	高（线程栈约MB级）
复杂度	中（需理解环形缓冲区设计）	高（需适应消息驱动范式）	低（类似同步代码编写）	中（需处理锁和同步）

3.2.2 线程池配置方案

动态配置

将线程池的参数从代码中迁移到分布式配置中心上，实现线程池参数可动态配置和即时生效。

3.3 动态化线程池

3.3.1 线程池参数

动态化线程池的核心设计包括以下三个方面：

1. 简化线程池配置：线程池构造参数有8个，但是最核心的是3个：corePoolSize、maximumPoolSize，workQueue。

   它们最大程度地决定了线程池的任务分配和线程分配策略。考虑到在实际应用中我们获取并发性的场景主要是两种：

   （1）并行执行子任务，提高响应速度。这种情况下，应该使用同步队列，没有什么任务应该被缓存下来，而是应该立即执行。

   （2）并行执行大批次任务，提升吞吐量。这种情况下，应该使用有界队列，使用队列去缓冲大批量的任务，队列容量必须声明，防止任务无限制堆积。所以线程池只需要提供这三个关键参数的配置，并且提供两种队列的选择，就可以满足绝大多数的业务需求，Less is More。

2. 参数可动态修改：为了解决参数不好配，修改参数成本高等问题。在Java线程池留有高扩展性的基础上，封装线程池，允许线程池监听同步外部的消息，根据消息进行修改配置。将线程池的配置放置在平台侧，允许开发同学简单的查看、修改线程池配置。

3. 增加线程池监控：对某事物缺乏状态的观测，就对其改进无从下手。在线程池执行任务的生命周期添加监控能力，帮助开发同学了解线程池状态。

3.3.2 线程池功能

动态调参：支持线程池参数动态调整、界面化操作；包括修改线程池核心大小、最大核心大小、队列长度等；参数修改后及时生效。

任务监控：支持应用粒度、线程池粒度、任务粒度的Transaction监控；可以看到线程池的任务执行情况、最大任务执行时间、平均任务执行时间、95/99线等。

负载告警：线程池队列任务积压到一定值的时候会通过大象（美团内部通讯工具）告知应用开发负责人；当线程池负载数达到一定阈值的时候会通过大象告知应用开发负责人。

操作监控：创建/修改和删除线程池都会通知到应用的开发负责人。

操作日志：可以查看线程池参数的修改记录，谁在什么时候修改了线程池参数、修改前的参数值是什么。

权限校验：只有应用开发负责人才能够修改应用的线程池参数。

参数动态化

JDK原生线程池ThreadPoolExecutor提供了如下几个public的setter方法

JDK允许线程池使用方通过ThreadPoolExecutor的实例来动态设置线程池的核心策略，以setCorePoolSize为方法例，在运行期线程池使用方调用此方法设置corePoolSize之后，线程池会直接覆盖原来的corePoolSize值，并且基于当前值和原始值的比较结果采取不同的处理策略。对于当前值小于当前工作线程数的情况，说明有多余的worker线程，此时会向当前idle的worker线程发起中断请求以实现回收，多余的worker在下次idel的时候也会被回收；对于当前值大于原始值且当前队列中有待执行任务，则线程池会创建新的worker线程来执行队列任务

线程池监控

除了参数动态化之外，为了更好地使用线程池，我们需要对线程池的运行状况有感知，比如当前线程池的负载是怎么样的？分配的资源够不够用？任务的执行情况是怎么样的？是长任务还是短任务？基于对这些问题的思考，动态化线程池提供了多个维度的监控和告警能力，包括：线程池活跃度、任务的执行Transaction（频率、耗时）、Reject异常、线程池内部统计信息等等，既能帮助用户从多个维度分析线程池的使用情况，又能在出现问题第一时间通知到用户，从而避免故障或加速故障恢复。

1. 负载监控和告警

事前，线程池定义了“活跃度”这个概念，来让用户在发生Reject异常之前能够感知线程池负载问题，线程池活跃度计算公式为：线程池活跃度 = activeCount/maximumPoolSize。这个公式代表当活跃线程数趋向于maximumPoolSize的时候，代表线程负载趋高。

事中，也可以从两方面来看线程池的过载判定条件，一个是发生了Reject异常，一个是队列中有等待任务（支持定制阈值）。以上两种情况发生了都会触发告警，告警信息会通过大象推送给服务所关联的负责人。

2. 任务级精细化监控

假设业务开发申请了一个线程池同时用于执行两种任务，一个是发消息任务、一个是发短信任务，这两类任务实际执行的频率和时长对于用户来说没有一个直观的感受，很可能这两类任务不适合共享一个线程池，但是由于用户无法感知，因此也无从优化。

而动态化线程池内部实现了任务级别的埋点，且允许为不同的业务任务指定具有业务含义的名称，线程池内部基于这个名称做Transaction打点，基于这个功能，用户可以看到线程池内部任务级别的执行情况，且区分业务，任务监控示意图如下图所示：

3. 运行时状态实时查看

用户基于JDK原生线程池ThreadPoolExecutor提供的几个public的getter方法，可以读取到当前线程池的运行状态以及参数，如下图所示：

动态化线程池基于这几个接口封装了运行时状态实时查看的功能，用户基于这个功能可以了解线程池的实时状态，比如当前有多少个工作线程，执行了多少个任务，队列中等待的任务数等等。

3.4 实践总结

面对业务中使用线程池遇到的实际问题，我们曾回到支持并发性问题本身来思考有没有取代线程池的方案，也曾尝试着去追求线程池参数设置的合理性，但面对业界方案具体落地的复杂性、可维护性以及真实运行环境的不确定性，我们在前两个方向上可谓“举步维艰”。最终，我们回到线程池参数动态化方向上探索，得出一个且可以解决业务问题的方案，虽然本质上还是没有逃离使用线程池的范畴，但是在成本和收益之间，算是取得了一个很好的平衡。成本在于实现动态化以及监控成本不高，收益在于：在不颠覆原有线程池使用方式的基础之上，从降低线程池参数修改的成本以及多维度监控这两个方面降低了故障发生的概率。希望本文提供的动态化线程池思路能对大家有帮助。