守护线程必须在start()前调用setDaemon(true)，否则抛IllegalThreadStateException；设为true后不可逆，默认为false；JVM退出时不等待其完成，适用于监控等允许丢失数据的场景，不适用于文件写入等需确保完成的任务。

守护线程必须在 start() 之前设置

调用 Thread.setDaemon(true) 生效的前提是线程尚未启动。一旦执行了 thread.start()，再调用该方法会直接抛出 IllegalThreadStateException。这是最常踩的坑——很多人习惯先 new Thread，再配置，最后 start，却把 setDaemon(true) 放在 start() 后面。

• ✅ 正确顺序：thread.setDaemon(true) → thread.start()
• ❌ 错误写法：thread.start() → thread.setDaemon(true)（运行时报错）
• 守护状态不可逆：设为 true 后不能改回 false；未设置则默认为 false（即用户线程）

守护线程退出时不会等待其完成

JVM 仅在所有非守护线程（即用户线程）结束时才退出。守护线程会被强制终止，无论它是否还在执行 I/O、循环或 sleep。这对“后台清理任务”很关键：如果你指望它刷完缓存、关掉连接、写完日志，那大概率失败。

• 适用场景：周期性检查、内存软引用清理、监控上报（允许丢失少量数据）
• 不适用场景：文件写入、数据库事务提交、网络请求响应（需确保完成）
• 没有 finally 保证：线程被杀时，try-finally 中的 finally 不会执行

常见误用：混淆守护线程和 ExecutorService 的后台任务

很多人想用守护线程替代定时清理，结果发现线程池里的任务不受 setDaemon(true) 控制——因为 ExecutorService 创建的线程由内部线程工厂管理，不是你手动 new 出来的那个对象。

• ❌ 错误示范：new ThreadPoolExecutor(...).submit(() -> { /* 清理逻辑 */ }); + 对 executor 对象调 setDaemon（无效，ExecutorService 没这个方法）
• ✅ 正确做法：自定义 ThreadFactory，在 newThread 中显式设置 daemon = true
• 示例关键行：t.setDaemon(true); return t;（在 ThreadFactory.newThread() 内）

验证守护状态是否生效

别只信代码逻辑，运行时确认更可靠。可通过 thread.isDaemon() 或线程 dump 观察，但要注意：主线程默认不是守护线程，且它的状态不影响子线程。

• 调试建议：在 run() 方法开头加 System.out.println(Thread.currentThread().isDaemon());
• JVM 退出前可打印所有线程：Thread.getAllStackTraces().keySet().forEach(t -> System.out.println(t.getName() + ": " + t.isDaemon()));
• 注意 IDE 运行环境干扰：某些 IDE（如 IntelliJ）会注入守护线程，导致观察结果混杂

守护线程不是“后台优雅退出”的银弹，它是 JVM 级别的粗粒度生命周期控制。清理任务若涉及资源释放，优先考虑显式 shutdown 配合 CountDownLatch 或 ExecutorService.awaitTermination()，而不是依赖守护属性。