setDaemon(true)必须在start()前调用，否则抛IllegalThreadStateException；守护线程不阻止JVM退出，仅剩守护线程时JVM立即终止，不适合需善后任务。
守护线程不能靠 setDaemon(true) “启动后设置”——必须在 start() 之前调用，否则抛 IllegalThreadStateException。
setDaemon(true) 必须在 start() 前调用
这是最常踩的坑：线程一旦进入 RUNNABLE 或已启动状态，再调用 setDaemon() 就会失败。
-
setDaemon()只能在线程处于NEW状态时生效 - 调用
thread.start()后再执行thread.setDaemon(true)→ 直接抛出IllegalThreadStateException - 如果用
ExecutorService，无法通过该接口设置守护线程，得自己封装ThreadFactory
正确写法示例：
Thread t = new Thread(() -> {
while (true) {
System.out.println("守护任务运行中...");
try { Thread.sleep(1000); } catch (InterruptedException e) { break; }
}
});
t.setDaemon(true); // ✅ 必须在这行
t.start(); // ✅ 再启动
守护线程退出时机：JVM 仅剩守护线程时立即终止
守护线程不会阻止 JVM 退出；它的生命周期完全依附于用户线程。
立即学习“Java免费学习笔记（深入）”；
- 只要所有非守护线程（包括 main）结束，JVM 就直接 shutdown，不会等待守护线程完成当前逻辑
- 守护线程中
finally块、shutdown hook不会执行 - 不适合做日志刷盘、资源释放等需要“善后”的任务（应改用
try-with-resources或显式close()）
典型误用场景：
t.setDaemon(true); t.start(); // main 线程立刻 return → JVM 退出，t 被强制中断，log 可能没写完
和用户线程对比：关键行为差异
理解“守护”本质，关键看 JVM 的退出策略和线程调度无关。
- 守护线程优先级可以和用户线程一样，
setPriority()不影响其“守护”属性 - 守护线程也能被
interrupt()、能抛异常、能持有锁——只是 JVM 不等它 -
Thread.currentThread().isDaemon()可用于判断当前是否在守护线程中执行（比如某些框架内部逻辑需规避） - 子线程默认继承父线程的 daemon 状态，所以 main 启动的线程默认是用户线程，它创建的子线程也默认是用户线程
实际适合做什么：轻量、可丢弃的后台任务
别把它当“后台服务”，它更像一个“随叫随到、说走就走”的协作者。
- 监控类任务：如定期打印堆内存使用率（
ManagementFactory.getMemoryMXBean()） - 心跳上报：向管理端发送存活信号，断连无影响
- 缓存预热/清理：定时扫描弱引用队列（
ReferenceQueue），不保证每次都能跑完 - 避免用它做数据库连接池维护、文件写入、网络请求重试——这些必须由用户线程保障完成
复杂点在于：你没法可靠地“通知守护线程优雅退出”，因为 JVM 退出不发信号。真需要可控生命周期，就别设成守护线程。
