Java线程池无内置terminated hook，需用shutdown()配合awaitTermination()确认终止后执行清理；推荐该方式因可控性强、无竞态风险；禁用轮询或反射等不安全手段。
Java 中的线程池（如 ThreadPoolExecutor）本身**没有内置的 "terminated hook" 方法**，但可以通过组合使用 shutdown()、awaitTermination() 和自定义逻辑，在线程池**确认完全终止后**执行系统级变量清理。关键不是“钩子”，而是**可靠地感知终止状态并执行清理**。
利用 awaitTermination + 后置清理（最常用且可靠）
这是生产环境推荐做法：主动关闭线程池，等待其真正结束，再执行清理逻辑。它不依赖回调，可控性强，无竞态风险。
- 调用
executor.shutdown()发起关闭，拒绝新任务 - 调用
executor.awaitTermination(timeout, unit)阻塞等待所有任务完成（包括已提交但未开始的） - 检查返回值：若为
true，说明线程池已终止；若为false，可选择强制 shutdownNow 或记录告警 - 在确认终止后，立即执行你的系统级变量清理（如清空静态缓存、注销 MBean、关闭底层连接池等）
示例：
executor.shutdown();<br>if (executor.awaitTermination(30, TimeUnit.SECONDS)) {<br> // ✅ 确认终止，执行清理<br> clearGlobalCache();<br> deregisterMetrics();<br> closeUnderlyingDataSource();<br>} else {<br> // ⚠️ 超时未终止，按需处理（如日志、强制终止、或延迟重试）<br did not terminate gracefully>}
继承 ThreadPoolExecutor 并重写 terminated()（有限适用）
ThreadPoolExecutor.terminated() 是一个受保护的空方法，设计初衷就是供子类扩展——当线程池从 TERMINATED 状态切换完成时被调用（注意：不是“即将终止”，而是“已经终止完毕”）。它在线程池内部状态机中被安全调用，是真正的“终止钩子”。
- 必须继承
ThreadPoolExecutor，并在构造后确保该实例被全程使用 - 重写的
terminated()方法会在**所有工作线程退出、内部状态锁释放、线程池彻底进入 TERMINATED 状态后**被调用 - 该方法运行在某个工作线程（通常是最后一个退出的线程）上，因此需保证清理逻辑是线程安全的，且不能阻塞过久（否则会拖慢整个 JVM 关闭流程）
- 适用于需要与线程池生命周期强绑定的轻量级清理（如释放线程局部资源、更新原子计数器），不适合耗时操作（如 I/O、网络调用）
示例：
public class CleanableThreadPool extends ThreadPoolExecutor {<br> public CleanableThreadPool(...) { super(...); }<br> @Override<br> protected void terminated() {<br> super.terminated();<br> // ✅ 此处执行清理<br> MyGlobalRegistry.remove(this);<br> ThreadLocalCleaner.cleanup();<br> }<br>}
结合 JVM Shutdown Hook 做兜底（增强健壮性）
单独依赖 terminated() 或 awaitTermination 可能遗漏异常退出（如 kill -9、OOM crash）。Shutdown Hook 可作为补充机制，确保 JVM 退出前至少尝试一次清理。
- 注册 hook 时，应检查线程池是否已处于
isTerminated()状态，避免重复清理 - hook 中不应调用
shutdown()或awaitTermination()（JVM 正在关闭，线程池可能已卡死或不可控） - 只做幂等、快速、无依赖的清理（如
static Map.clear()、AtomicBoolean.set(false)） - 不替代主动关闭流程，仅作最后防线
示例：
Runtime.getRuntime().addShutdownHook(new Thread(() -> {<br> if (executor != null && executor.isTerminated()) {<br> cleanupSystemResources(); // 快速、幂等<br> }<br>}));
不推荐：监听线程池状态轮询或反射修改
通过定时检查 isTerminated() 实现“钩子”效率低、实时性差，还可能引入忙等；通过反射强行调用内部方法或修改状态，破坏封装、兼容性差、极易出错，JDK 升级后大概率失效。这些方式在生产系统中应避免。
