shutdown() 优雅关闭，等待任务完成；shutdownNow() 强制中断，尝试停止运行任务并清空队列；二者均需配合 awaitTermination() 等待终止并清理引用才能确保资源释放。
Java 线程池关闭时，shutdown() 和 shutdownNow() 的核心区别在于：前者尝试优雅终止（等待已有任务完成），后者强制中断（尝试停止正在执行的任务并清空队列）。资源能否被正确回收，关键不在于调用哪个方法，而在于是否完成“线程池生命周期终结”的完整动作——即：触发关闭 → 等待终止 → 释放引用。
shutdown()：适合有任务需自然结束的场景
调用 shutdown() 后，线程池不再接受新任务，但会继续执行已提交到队列中的任务和正在运行的任务。资源不会立即释放，必须配合 awaitTermination() 等待所有任务真正结束，JVM 才可能回收线程池持有的线程、队列、锁等资源。
- 推荐写法：先 shutdown()，再用 awaitTermination() 等待合理超时（如 60 秒），超时后可考虑 fallback 行为
- 注意：awaitTermination() 返回 false 并不表示失败，只是说明还没结束；此时不应反复调用，而应判断是否需要升级为 shutdownNow()
- 常见误区：只调用 shutdown() 就认为线程池已“关闭”，实际线程仍存活，队列未清空，GC 无法回收
shutdownNow()：用于快速释放资源，但不保证任务安全退出
shutdownNow() 会尝试中断所有正在执行的任务，并返回尚未执行的任务列表（从阻塞队列中“拔出”）。它比 shutdown() 更激进，但中断只是协作机制：如果任务未响应中断（比如没检查 Thread.interrupted() 或未捕获 InterruptedException），就可能继续运行，导致资源滞留。
- 调用后仍建议调用 awaitTermination()，确认线程是否真正终止
- 返回的 List
是未执行任务的快照，应显式处理（如记录日志或重新提交） - 不要依赖 shutdownNow() 实现“100%立即释放”——线程真正销毁由 JVM 调度，取决于任务是否及时响应中断
真正释放资源的关键动作：等待 + 引用清理
无论用哪种关闭方式，线程池对象本身（ThreadPoolExecutor 实例）只有在所有工作线程终止 + 无活跃引用指向该线程池**时，才能被 GC 回收。线程池内部的线程是用户线程（非守护线程），只要还在运行，就会阻止 JVM 退出，也阻碍资源释放。
立即学习“Java免费学习笔记（深入）”；
- 务必在业务逻辑结束处调用 shutdown() 或 shutdownNow()，并在 finally 块或 try-with-resources（若自定义了 AutoCloseable 包装）中确保执行
- 避免将线程池设为 static 或长期持有强引用；用完及时置 null（尤其在短生命周期对象中）
- 可借助 JConsole 或 VisualVM 观察线程数变化，验证 shutdown + awaitTermination 是否真正生效
实用建议：封装成可关闭的组件
在 Spring 等容器中，可通过 @PreDestroy 注解自动关闭；在普通 Java 应用中，建议把线程池包装为一个 Lifecycle 类，统一管理初始化与关闭流程：
- start() 中创建并启动线程池
- stop() 中调用 shutdown() → awaitTermination() → shutdownNow()（超时后兜底）→ 置空引用
- 任务实现 Runnable/Callable 时，主动检查中断状态，及时退出循环或释放本地资源（如文件句柄、数据库连接）
