runtime.getruntime().addshutdownhook() 是 jvm 关闭时执行清理逻辑的兜底机制，用于正常退出场景（如 system.exit、ctrl+c），不适用于 kill -9 或崩溃；其本质是未启动的非守护线程，jvm 会并发执行所有注册钩子，无序且不可依赖状态，需短时、容错、避免阻塞。
java 中通过 runtime.getruntime().addshutdownhook() 可以在 jvm 正常关闭（如调用 system.exit()、用户中断 ctrl+c、或主进程自然结束）时，执行自定义清理逻辑。但要注意：它不适用于强制 kill（如 kill -9）、jvm 崩溃或断电等场景。
什么是 Shutdown Hook
Shutdown Hook 是一个已启动但尚未运行的 Thread 对象，由 JVM 在关闭序列中自动启动并执行。它不是守护线程，JVM 会等待所有 shutdown hook 执行完毕才真正退出（除非超时或被强制终止）。
关键特性：
- 多个 hook 没有固定执行顺序，不可依赖先后关系
- 不能在 hook 中调用
System.exit()，否则会死锁 - 不能假定其他 hook 或应用资源仍处于可用状态（例如网络连接可能已断开、日志器可能已关闭）
- 执行时间应尽量短；长时间阻塞会影响 JVM 退出，甚至触发强制终止
正确注册和编写 Shutdown Hook
推荐将清理逻辑封装为独立线程，并避免在 hook 中做复杂调度或同步操作：
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
System.out.println("正在释放数据库连接...");
if (dataSource != null) {
try {
dataSource.close(); // 或调用连接池的 close()
} catch (Exception e) {
// 记录日志（确保日志系统此时仍可用）
System.err.println("关闭数据源失败: " + e.getMessage());
}
}
System.out.println("正在关闭文件写入流...");
if (fileWriter != null) {
try {
fileWriter.close();
} catch (IOException e) {
System.err.println("关闭文件流失败: " + e.getMessage());
}
}
}));
更安全的做法是使用 Lambda 表达式 + 显式异常处理，避免未捕获异常导致 hook 提前退出（JVM 不会因单个 hook 异常而中止其他 hook）。
常见陷阱与规避方式
实际使用中容易踩坑，以下问题需特别注意：
-
资源状态不确定：比如数据库连接可能已在业务中提前关闭，再次 close 可能抛出异常。建议加判空或忽略特定异常（如
IllegalStateException） -
日志失效：若使用 Logback/Log4j 等框架，其内部 shutdown hook 可能比你的先执行，导致
logger.info()静默失败。建议用System.err或确保日志器未关闭 - 线程安全问题：hook 中访问的共享资源（如缓存、计数器）应保证线程安全，或确认此时无其他线程并发修改
- 无法取消已注册的 hook：JDK 没有提供 removeShutdownHook 的公开 API（虽有内部方法，但不推荐使用）。如需动态控制，可自行维护开关标志位
替代方案与补充建议
对于更复杂的生命周期管理，单纯依赖 shutdown hook 并不足够：
- 使用 try-with-resources 管理单次作用域内的资源（如文件、Socket），比全局 hook 更精准可靠
- 在 Spring 等容器中，优先使用
@PreDestroy、DisposableBean或SmartLifecycle接口，它们由容器统一协调，支持依赖顺序 - 对关键服务（如消息队列消费者），可在 shutdown hook 中发送“下线通知”，再等待几秒确保消息处理完成，而非直接终止
- 测试时可通过
System.exit(0)触发 hook，但生产环境应避免随意调用，尤其在 Web 容器中可能影响整个应用
不复杂但容易忽略：shutdown hook 是 JVM 关闭阶段的“最后一道防线”，不是资源管理的首选手段，而是兜底保障。设计时应让核心资源具备自动清理能力，再用 hook 做最终确认与补救。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
