4. 线程池状态与生命周期管理

线程池并不是“创建后一直可用、调用 shutdown 就立刻消失”的黑盒。在 Java 的 ThreadPoolExecutor 中，线程池自身有一个明确的生命周期状态机，它由内部一个 32 位整数的高 3 位表示，低 29 位同时保存着当前工作线程数量。理解这五个状态以及它们之间的流转条件，是排查“任务为什么不执行”“线程为什么回收不掉”“关闭为什么卡住”等问题的关键。

五个状态的定义与工程含义

线程池的五个状态按数值递增排列，分别是 RUNNING、SHUTDOWN、STOP、TIDYING、TERMINATED。它们不是并列的开关，而是一条单向推进的生命周期链，只能从低数值向高数值迁移，不能回退。

• RUNNING：线程池处于正常工作状态，接受新提交的任务，同时也会继续处理阻塞队列中已积压的任务。这是线程池创建后的初始状态。
• SHUTDOWN：调用 shutdown() 后进入。此时不再接受新任务，但会继续执行队列中已经存在的任务，属于“温和关闭”。
• STOP：调用 shutdownNow() 后进入。既不接受新任务，也不处理队列中剩余任务，同时会尝试中断正在执行的任务，属于“强制关闭”。
• TIDYING：当所有任务都已终止、工作线程数为 0 时进入的过渡状态。此时会执行 terminated() 钩子方法，通常用于资源清理。
• TERMINATED：terminated() 执行完毕后进入的终态，表示线程池彻底结束，无法再被复用。

这里有一个容易被忽略的工程细节：SHUTDOWN 与 STOP 的核心区别不在于“是否关闭”，而在于“对队列中任务和正在执行任务的处理策略”。SHUTDOWN 尊重已提交的任务，STOP 则直接放弃队列并中断执行中的线程。选择哪一个，取决于业务对“任务完整性”和“关闭速度”的权衡。

状态流转的触发条件

从 RUNNING 出发有两条分支。调用 shutdown() 进入 SHUTDOWN；调用 shutdownNow() 进入 STOP。这两条路径的差异会直接影响后续行为：SHUTDOWN 会等待队列任务执行完，STOP 则立即清空队列并中断线程。

SHUTDOWN 和 STOP 都会在“工作线程数降为 0”时进入 TIDYING。区别在于 SHUTDOWN 需要额外满足“队列为空”这一条件，因为它的语义是“把已提交的任务做完”；而 STOP 不关心队列，只要线程都停了就可以进入 TIDYING。进入 TIDYING 后，线程池会调用一次 terminated() 钩子，随后状态置为 TERMINATED，整个生命周期结束。

需要特别强调的是：状态只能单向推进。一旦进入 SHUTDOWN 或 STOP，就不可能再回到 RUNNING。这意味着线程池一旦开始关闭，就不能通过任何公开 API 重新激活，只能重新创建一个新的线程池实例。

工程实践中的关键判断

在实际工程中，最常遇到的困惑是“调用了 shutdown，为什么任务还在跑”。这正是 SHUTDOWN 的设计意图：它不丢弃队列任务。如果希望快速停止并放弃未执行任务，应使用 shutdownNow()，但要注意它返回的是“尚未开始执行的任务列表”，这些任务需要业务自行决定是否补偿处理。

另一个常见问题是“shutdown 之后线程池一直不结束”。原因通常是队列中还有任务，或者有任务长时间阻塞导致工作线程无法退出。此时可以通过 awaitTermination(timeout, unit) 设置等待上限，超时后根据业务需要决定是否升级为 shutdownNow()。

// 推荐的优雅关闭模板（示例参数，非实测结果）
executor.shutdown();                       // 进入 SHUTDOWN
try {
    if (!executor.awaitTermination(30, TimeUnit.SECONDS)) {
        executor.shutdownNow();            // 超时升级为 STOP
        if (!executor.awaitTermination(10, TimeUnit.SECONDS)) {
            log.warn("线程池未能完全终止");
        }
    }
} catch (InterruptedException e) {
    executor.shutdownNow();
    Thread.currentThread().interrupt();
}

这段模板体现了状态机的实际用法：先温和关闭，给队列任务一个完成窗口；超时后再强制关闭，避免无限等待。判断是否真正终止，依据是 awaitTermination 的返回值，而不是主观等待。

状态与任务提交的交互

状态不仅影响关闭行为，也直接决定新任务能否被接受。在 RUNNING 状态下，execute() 会正常走“核心线程—队列—非核心线程—拒绝策略”的流程。一旦进入 SHUTDOWN 或 STOP，任何新提交的任务都会直接触发拒绝策略，而不会进入队列。因此，如果业务在关闭过程中仍可能提交任务，必须为拒绝策略设计好降级逻辑，例如记录日志、落库补偿或返回失败结果。

把状态机理解为线程池的“生命周期契约”，就能在设计和排障时做出更准确的判断：关闭方式决定任务是否被尊重，状态数值决定线程池是否还能被使用，而 terminated() 钩子则提供了资源清理的最后时机。