钩子只在JVM正常关闭流程中执行，如调用System.exit()、收到SIGTERM（kill -15）、Ctrl+C或容器优雅终止；不响应kill -9、JVM崩溃、OOM宕机或断电等场景。
什么时候钩子会真正起作用
钩子只在JVM**正常关闭流程中执行**，比如调用 System.exit()、收到 SIGTERM（kill -15）、用户按 Ctrl+C、或容器平台发起优雅终止。它不会响应 kill -9（SIGKILL）、JVM崩溃、内存溢出直接宕机、断电等场景——这些情况下钩子完全不运行。
常见误判：本地 Ctrl+C 能触发，但上线 K8s 后没反应，大概率是容器未配置 terminationGracePeriodSeconds，或启动脚本用了 exec java ... 导致信号未转发到 Java 进程。
释放变量和资源的关键原则
钩子线程里不能依赖“还在运行”的业务状态。变量如果是局部的、未被其他线程共享的，钩子中访问可能已失效；如果是静态或全局对象，需确保其生命周期覆盖到钩子执行时刻，且访问是线程安全的。
- 优先使用volatile 标记 + 主动检查，而不是在钩子里读取守护线程中的实时变量
- 数据库连接、文件流、Netty EventLoopGroup 等资源，必须调用明确的 close() / shutdownGracefully() 方法
- 所有阻塞操作必须设超时，例如
group.shutdownGracefully().await(3, TimeUnit.SECONDS)，避免卡住 JVM 关闭 - 不要在钩子里做日志刷盘（AsyncLogger 可能已停）、同步写 DB 或发 HTTP 请求——这些极易超时或失败
典型资源释放代码模式
以下写法兼顾安全性与可维护性：
// 示例：释放 HikariCP 数据源 + Netty 资源 + 临时文件
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
System.out.println("开始执行关闭钩子");
// 1. 关闭数据源（支持 close() 的连接池）
if (dataSource != null) {
try { dataSource.close(); } catch (Exception e) {
System.err.println("关闭数据源异常：" + e.getMessage());
}
}
// 2. 优雅关闭 Netty EventLoopGroup
if (eventLoopGroup != null && !eventLoopGroup.isTerminated()) {
try {
eventLoopGroup.shutdownGracefully()
.await(3, TimeUnit.SECONDS);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
}
}
// 3. 删除临时目录（非阻塞、无异常传播风险）
try {
Files.walk(tempDir)
.sorted(Comparator.reverseOrder())
.forEach(path -> {
try { Files.deleteIfExists(path); } catch (IOException ignored) {}
});
} catch (IOException ignored) {}
System.out.println("关闭钩子执行完成");
}));
容易忽略的实战陷阱
-
注册时机太晚：必须在 main 返回前、或 Spring 上下文刷新完成后注册；一旦 JVM 开始关闭序列，再 add/remove 都会抛
IllegalStateException，且静默失败 - 多个钩子无序执行：不要让 A 钩子关连接、B 钩子写日志，还指望 B 一定在 A 之后——应合并进同一个线程内串行处理
-
日志系统可能已不可用：Log4j2 的异步日志器在关闭阶段常处于“队列冻结”状态，建议用
System.err.println或提前配置同步日志器兜底 -
Spring Boot 默认有超时：
spring.lifecycle.timeout-per-shutdown-phase=30s，超时后直接中断钩子线程，所以耗时操作必须自己控制超时
