从一次线上故障复盘：ThreadPoolExecutor的shutdownNow为什么没停掉我的任务？

线程池关闭陷阱：为什么shutdownNow无法终止你的任务？

凌晨三点，监控系统突然告警——核心服务在滚动发布后出现长达15分钟的请求堆积。运维团队紧急介入，发现旧实例的JVM进程迟迟不退，日志中仍有大量任务在执行。这一切的罪魁祸首，竟是一个被误用的ThreadPoolExecutor.shutdownNow()调用。本文将带你深入线程池关闭机制的底层原理，还原故障排查全过程，并给出可落地的解决方案。

1. 线程池关闭的三重门

1.1 shutdown的温和之道

当调用shutdown()时，线程池进入SHUTDOWN状态，此时：

• 队列消化模式：继续执行已提交的任务
• 拒绝新任务：新提交的任务会触发RejectedExecutionException
• 无强制中断：不会对运行中的线程调用interrupt()

// 典型的安全关闭模式
executor.shutdown();
if (!executor.awaitTermination(60, TimeUnit.SECONDS)) {
    executor.shutdownNow();
}

1.2 shutdownNow的激进尝试

shutdownNow()将线程池状态升级为STOP，其行为特征包括：

List<Runnable> rejectedTasks = executor.shutdownNow();
log.warn("丢弃未执行任务：{}", rejectedTasks.size());

1.3 awaitTermination的等待艺术

这个方法经常被误解，关键点在于：

• 纯等待机制：不改变线程池状态
• 双返回值语义：
  • true：线程池已达TERMINATED状态
  • false：超时后仍未终止
• 典型误用：

  // 错误用法！缺少shutdown触发
  executor.awaitTermination(10, TimeUnit.SECONDS);
  

2. 故障现场还原

2.1 诡异的线程存活现象

在案例中，即使调用了shutdownNow()，监控仍显示：

• 线程池中的worker线程持续活跃
• 任务继续消耗CPU资源
• 最终导致旧实例无法及时下线