守护线程必须在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()，而不是依赖守护属性。
