守护线程不阻止JVM退出，JVM仅等待非守护线程终止；setDaemon(true)须在start()前调用，新线程继承父线程守护状态，退出时不执行finally或shutdown钩子。
守护线程不会阻止JVM退出
Java中，setDaemon(true) 的作用非常直接：标记当前线程为守护线程。JVM 退出的唯一条件是「所有非守护线程都已终止」——不是“所有线程”，也不是“主线程结束”，而是仅看非守护线程是否清空。一旦只剩守护线程在跑，JVM 立刻收工，不等、不通知、不执行 finally 或 JVM 关闭钩子。
- 常见错误现象：
Thread.sleep(5000)放在守护线程里，主线程一结束，整个程序瞬间退出，根本等不到那 5 秒 - 使用场景：日志刷盘、监控上报、连接心跳这类“辅助性后台任务”，它们本就不该决定程序生死
- 注意：
setDaemon()必须在start()之前调用，否则抛IllegalThreadStateException
主线程默认是非守护线程，但可以改
很多人误以为“主线程天生特殊”，其实它只是 JVM 启动时自动创建的第一个非守护线程。它的 isDaemon() 返回 false，但你完全可以在 main 方法开头就调 Thread.currentThread().setDaemon(true) —— 这会让主线程变成守护线程，结果就是：只要它一结束，JVM 立刻退出，哪怕你刚 new 出一个非守护子线程还没 start。
- 参数差异：
setDaemon(true)和setDaemon(false)的行为不对称：设为false是默认值，设为true才会改变线程角色；但设完就不能再改 - 容易踩的坑：在
main中启动守护线程后直接 return，没留任何非守护线程存活，JVM 零延迟退出 - 验证方式：加一句
System.out.println(Thread.currentThread().isDaemon());就能确认当前线程身份
守护线程里的子线程默认继承守护状态
新线程默认继承父线程的守护属性。也就是说，如果从一个守护线程里 new Thread(() -> {...})，这个新线程默认也是守护线程，除非你显式调 setDaemon(false)。
- 常见错误现象：用守护线程做定时任务调度器，它 spawn 的任务线程全成了守护线程，结果调度器一停，所有任务线程被 JVM 强制终结，任务无声丢失
- 使用场景：需要“派生出非守护工作线程”的守护调度器，必须手动重置：
t.setDaemon(false) - 性能影响：无直接开销，但逻辑错位会导致资源泄漏或任务截断，比性能问题更致命
JVM 退出时守护线程不保证执行完
这是最常被低估的一点：JVM 在判定退出时，对守护线程只做一件事——中断（interrupt）并释放资源。它不会等守护线程自然结束，也不会触发其 finally 块，更不会运行 Runtime.addShutdownHook() 里的逻辑（除非你把钩子本身注册在非守护线程里）。
立即学习“Java免费学习笔记（深入）”；
- 典型表现：守护线程正在写文件，JVM 退出导致文件写到一半、没 flush、没 close，内容损坏或丢失
- 解决方案：关键清理动作不能依赖守护线程的自然结束，要么挪到非守护线程中完成，要么用 shutdown hook 主动协调（hook 本身必须是非守护线程）
- 兼容性提醒：该行为在所有 JDK 版本中一致，不是 bug，是规范定义
真正麻烦的是那种“以为线程还在跑，其实已被 JVM 悄悄掐掉”的情况——没有异常、没有日志、只有结果不对。盯住 isDaemon() 的返回值和线程生命周期边界，比加日志还管用。
