守护线程不阻止jvm退出，异常不会触发shutdownhook；钩子仅响应system.exit()、ctrl+c或kill -15，且不可靠——sigkill下完全不执行。
守护线程不会阻止JVM退出，异常也不会自动触发钩子
Java里setDaemon(true)只是告诉JVM：“这个线程不重要，主程序结束时不用等它”。哪怕它正在跑、甚至抛了未捕获异常，JVM照样直接退出——不会调用shutdownHook，也不会打印堆栈（除非你手动捕获）。很多人误以为“线程挂了就会触发钩子”，其实钩子只响应System.exit()、用户中断（Ctrl+C）、或进程被信号终止（如kill -15），跟线程是否异常无关。
常见错误现象：
• 启动一个守护线程做日志刷盘，主线程一结束，日志全丢
• 在守护线程里写try-catch捕获异常，但没处理InterruptedException或RuntimeException，线程静默死亡
• 把清理逻辑全塞进钩子，却忘了钩子本身没有线程上下文，不能依赖守护线程里的状态
- 守护线程适合做后台监控、心跳上报这类“可丢弃”任务，不适合承担关键清理职责
- 如果需要异常后执行清理，必须在线程内部自己捕获并显式调用清理函数，而不是指望钩子
- 钩子函数运行在
ShutdownHook线程中，不能做耗时操作（如网络请求、大文件IO），否则会阻塞JVM退出
System.addShutdownHook() 的正确注册时机和限制
钩子必须在JVM进入关闭序列前注册，最晚也要在主线程main()返回前完成。一旦开始执行钩子，再注册就无效，且不会报错——只是默默忽略。
使用场景：
• 关闭数据库连接池（如HikariDataSource.close()）
• 刷写缓存到磁盘（如Cache.flush()）
• 删除临时目录（Files.deleteIfExists(tempDir)）
立即学习“Java免费学习笔记（深入）”；
- 钩子不能保证执行顺序，多个钩子之间无依赖关系；若需顺序，应合并进同一个
Thread里串行调用 - 钩子中禁止调用
System.exit()或再次注册/移除钩子，会导致IllegalStateException - 在容器环境（如Docker）中，若进程收到
SIGKILL（kill -9），钩子**完全不会执行**——这是最常被忽略的兼容性盲点
守护线程 + 钩子组合使用的典型错误模式
比如想让守护线程监听配置变更，同时确保JVM退出时保存最后状态。结果代码写成：启动守护线程 → 注册钩子 → 主线程退出。问题来了：守护线程可能刚读到一半配置就没了，钩子又拿不到它的最新数据。
常见错误现象：
• 钩子里尝试访问守护线程的volatile变量，但该变量还没被更新（竞态）
• 守护线程用while(!Thread.interrupted())循环，但没在interrupt()后做清理，导致资源泄漏
• 钩子调用thread.join(1000)等守护线程结束，但守护线程根本不会响应中断（比如卡在阻塞IO）
- 共享状态必须用
volatile或Atomic*，且钩子读取前要确保线程已安全退出（推荐用CountDownLatch协调） - 守护线程的
run()里必须响应中断：检查Thread.currentThread().isInterrupted()，并在退出前释放资源 - 不要在钩子里
join()守护线程——它本就不该被等待；真要等，改用带超时的latch.await(3, TimeUnit.SECONDS)
替代方案：比守护线程+钩子更可靠的退出控制
当业务要求“必须做完某件事才退出”，靠守护线程和钩子拼凑容易失控。更可控的做法是放弃守护属性，改用普通线程配合显式生命周期管理。
例如用ExecutorService提交任务，主线程退出前调用shutdown() + awaitTermination()：
executor.shutdown();
if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
executor.shutdownNow(); // 强制中断
}
这样既能响应中断，又能控制超时，还能捕获RejectedExecutionException等异常。
- 所有需要“可靠清理”的逻辑，优先走显式关闭流程，而不是依赖JVM自动行为
- Spring Boot应用直接用
@PreDestroy或实现DisposableBean，底层已封装好钩子与线程协调 - 微服务场景下，还要考虑K8s的
preStophook和优雅停机信号传递，JVM钩子只是其中一环
真正麻烦的从来不是怎么写钩子，而是理清“谁该负责哪段清理”——线程、钩子、框架、容器，责任边界模糊时，代码就容易在某个信号下静默失败。
