根本原因是JVM未进入正常关闭流程；仅对SIGTERM、System.exit()、Ctrl+C等软终止有效，而kill-9、断电、崩溃等硬终止下钩子完全不执行。
Runtime.addShutdownHook() 为什么有时不触发
根本原因就一个：JVM 没有进入正常关闭流程。addShutdownHook() 只对 SIGTERM、System.exit()、控制台 Ctrl+C（终端发送 SIGINT）等软终止有效；而 KILL -9、断电、kill -9、JVM 崩溃或直接杀进程这些硬终止，钩子**完全不会执行**。
常见误判场景：
- 在 IDE 中点红色停止按钮 → 多数 IDE 用
kill -9强杀，钩子失效 - 打包成 Docker 容器后未配置
STOPSIGNAL SIGTERM，默认用KILL - 主线程抛出未捕获
OutOfMemoryError导致 JVM 异常退出，钩子跳过
如何正确注册 shutdown hook 并保证它可用
钩子本质是 Thread，必须在 JVM 启动后、关闭前注册；且一旦注册就不能取消。关键约束是：不能阻塞、不能依赖其他已销毁的资源（如已 close 的数据库连接）、不能调用 System.exit() 自己。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 尽早注册，比如
main()开头或 Spring Boot 的@PostConstruct阶段 - 用
setDaemon(false)（默认就是 false），避免被 JVM 忽略 - 捕获所有异常，防止钩子内抛异常导致整个 shutdown 流程中断
- 避免在钩子里做耗时操作（如网络请求、大文件写入），JVM 等待时间有限（无硬超时，但 OS 可能强制 kill）
示例：
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
try {
System.out.println("正在清理临时目录...");
Files.deleteIfExists(Paths.get("/tmp/app-lock"));
// 注意：此处不能用已被关闭的 logger 实例
} catch (Exception e) {
// 钩子内异常不会打印到控制台，建议写入文件或使用 System.err
System.err.println("清理失败：" + e.getMessage());
}
}));
和 Spring 的 DisposableBean / @PreDestroy 冲突吗
会，而且顺序不可控。Spring 容器关闭时会触发 @PreDestroy 和 DisposableBean.destroy()，但这发生在 Spring 上下文销毁阶段；而 shutdownHook 是 JVM 层级的，两者并行、无依赖关系。
实际风险：
- 若你在
@PreDestroy中关闭了线程池，钩子里又尝试提交任务 →RejectedExecutionException - 若钩子依赖 Spring Bean（如
DataSource），此时 Bean 已销毁，NPE 或 IllegalStateException
解决办法：只在钩子里做 JVM 级清理（如删临时文件、释放 native 资源、发信号给外部系统），把业务资源清理逻辑全交给 Spring 生命周期管理。
Docker 环境下怎么确保 shutdown hook 生效
Docker 默认用 kill -9 终止容器，钩子必然失效。必须显式配置信号传递：
- 启动容器时加
--stop-signal=SIGTERM - Dockerfile 中写
STOPSIGNAL SIGTERM - 避免用
exec java -jar app.jar启动 —— 这会让 Java 成为 PID 1，而 PID 1 对信号处理特殊；改用java -jar app.jar（不带 exec），让 shell 接收信号再转发
验证方式：容器运行中执行 docker kill --signal=SIGTERM <container-id>，观察日志是否输出钩子内容。
最常被忽略的一点：钩子线程没有上下文类加载器（contextClassLoader 为 null），如果清理逻辑里用了反射或 SPI 加载（比如 JDBC 驱动），可能 ClassNotFound。需要手动设置：Thread.currentThread().setContextClassLoader(MyApp.class.getClassLoader())。
