守护线程不执行finally、shutdown hook或未捕获异常处理器，JVM退出时直接强制终止；其仅适用于可丢弃的辅助任务，关键清理必须由非守护线程承担。
Java 中 setDaemon 方法本身不改变线程的异常处理机制，但它会彻底绕过异常终止后的常规清理流程——因为守护线程可能根本没机会执行异常处理逻辑。
守护线程异常不会触发未捕获处理器的可靠回调
虽然你可以为守护线程设置 Thread.setUncaughtExceptionHandler，但该处理器只有在线程“自然抛出未捕获异常”时才被调用。而 JVM 强制退出时（只剩守护线程），线程会被直接中断并销毁，既不抛异常，也不走异常分发路径。此时 handler 不会被触发，就像线程从未存在过一样。
finally 块和 shutdown 钩子一律失效
守护线程在 JVM 退出过程中不会获得执行 finally 的机会，也不会响应 Runtime.addShutdownHook()。例如：
- 一个守护线程正在写日志，内部有 try-finally 保证刷盘 → JVM 退出时，finally 被跳过，日志丢失
- 你注册了 shutdown hook 来关闭连接池 → 如果 hook 是在守护线程里注册的，它不会运行；即使注册在 main 线程，只要 JVM 因只剩守护线程而退出，hook 仍会执行（因为它属于非守护上下文），但守护线程自身已无响应能力
异常终止 ≠ JVM 退出，但守护状态放大风险
线程因未捕获异常而崩溃，和 JVM 因只剩守护线程而退出，是两件事。但二者叠加时问题更隐蔽：
立即学习“Java免费学习笔记（深入）”；
- 如果一个非守护工作线程因异常退出，又没有其他非守护线程存活，JVM 立即终止 → 此时所有正在运行的守护线程（比如监控、心跳）瞬间消失，连异常堆栈都来不及打印
- 开发者常误以为“加了 UncaughtExceptionHandler 就万无一失”，却忽略了：handler 只能救单个线程，救不了整个 JVM 的提前收场
正确应对策略：区分角色，不依赖守护线程做关键清理
真正需要异常恢复或资源释放的任务，必须运行在非守护线程中，并配合以下措施：
- 用
try-catch显式捕获运行时异常，避免未捕获崩溃 - 对关键资源（文件句柄、数据库连接）使用 try-with-resources 或在 finally 中强制释放
- 将 shutdown hook 注册在主线程或明确的非守护线程中，且只用于全局性收尾（如关闭共享资源池）
- 守护线程仅承担“可丢弃”的辅助任务：比如定期上报指标、发送心跳包——丢了不影响主业务完整性
