守护线程不阻塞JVM退出，JVM仅等待非守护线程结束便立即终止，强制中断所有守护线程且不执行finally或shutdown hook；setDaemon(true)必须在start()前调用，子线程默认继承父线程守护状态，适合纯辅助任务。
setDaemon 方法本身不主动“贡献”于应用终止，它只是标记线程角色；真正决定应用何时终止的，是 JVM 对守护线程与非守护线程的退出策略——JVM 仅等待所有非守护线程结束，之后立即退出，不等待、不清理守护线程。
守护线程不拖住 JVM 退出
只要所有非守护线程（包括主线程）执行完毕，JVM 就会终止进程。此时所有仍在运行的守护线程会被强制中断，不会执行剩余代码、不会触发 finally 块、也不会运行 shutdown hook。
- 典型表现：主线程启动一个守护线程后直接 return，程序瞬间退出，哪怕守护线程里写了 Thread.sleep(10000)
- 验证方式：在守护线程 run() 中加 System.out.println("still running...") 和 sleep，观察是否输出完整
- 关键点：不是“守护线程被杀死”，而是 JVM 根本不等它——退出动作与守护线程状态无关，只取决于非守护线程是否清空
必须在 start() 前设置
setDaemon(true) 是一次性配置，只能在线程处于新建状态（NEW）时调用。一旦 start() 执行，线程进入 RUNNABLE 状态，再调用 setDaemon 就会抛 IllegalThreadStateException。
- 错误写法：new Thread(() -> {}).start().setDaemon(true) —— 编译不过，且逻辑无效
- 正确顺序：Thread t = new Thread(...); t.setDaemon(true); t.start();
- 主线程也可设为守护：Thread.currentThread().setDaemon(true)，但这样会导致它一结束 JVM 就退出，即使子线程还没 start
子线程默认继承守护属性
新线程默认沿用父线程的 isDaemon() 值。如果从守护线程中创建新线程，该子线程默认也是守护线程，除非显式调用 setDaemon(false)。
立即学习“Java免费学习笔记（深入）”；
- 常见陷阱：守护型调度器（如定时任务线程池）派生的任务线程全为守护态，导致任务无声丢失
- 安全做法：在守护线程内创建工作线程时，明确重置：Thread worker = new Thread(task); worker.setDaemon(false); worker.start();
- 判断依据：Thread.currentThread().isDaemon() 可随时检查当前上下文是否为守护环境
它不提供资源清理能力
很多人误以为设为守护线程就能“优雅收尾”，实际恰恰相反：JVM 退出时，守护线程不保证任何清理行为。
- finally 不执行、close() 不调用、shutdown hook 不触发（除非注册在非守护线程中）
- 真正需要可靠清理的逻辑（如刷盘日志、关闭连接），应放在非守护线程中，并配合 try-finally 或 shutdown hook
- 守护线程适合纯辅助任务：心跳检测、指标上报、后台缓存刷新——这些任务中断不影响主业务完整性
