合理配置守护线程的关键是确保它本来就不会阻止jvm退出；必须在start()前调用setdaemon(true)，否则抛illegalthreadstateexception；守护线程仅用于纯后台支撑，不可承担事务、资源释放等关键任务。
合理配置守护线程的关键，不是“防止它阻止 JVM 退出”，而是确保它**本来就不会阻止**——前提是用法正确。真正容易出问题的，是误把该由非守护线程承担的任务交给了守护线程，或者设置时机/继承关系没理清，导致 JVM 提前退出或任务静默丢失。
必须在 start() 前设为守护线程
这是硬性约束，不是建议。一旦线程进入 RUNNABLE 状态（即调用 start() 后），再调 setDaemon(true) 就会抛 IllegalThreadStateException。
- ✅ 正确写法：Thread t = new Thread(() -> {...}); t.setDaemon(true); t.start();
- ❌ 错误写法：Thread t = new Thread(() -> {...}); t.start(); t.setDaemon(true); // 运行时异常
- 调试技巧：可通过 t.getState() == Thread.State.NEW 判断是否处于可设置状态
明确区分“该谁干活”：守护线程只做纯后台支撑
守护线程的本质角色是“服务者”，不是“执行者”。它的存在只为让其他线程更稳、更高效，本身不承载任何不可中断的业务逻辑。
- ✅ 合适场景：异步刷日志缓冲区、定期上报监控指标、维持 TCP 心跳连接、JMX 状态轮询
- ❌ 绝对避免：关闭数据库连接池、提交事务、上传文件分片、确认消息已消费——这些必须由非守护线程完成，否则 JVM 一收尾，操作直接中断，资源泄漏或数据不一致
- 注意：Spring 的 @Async 默认线程是非守护的；若需守护行为，得配 ThreadPoolTaskExecutor 并显式设 setDaemon(true)
警惕子线程自动继承守护属性
新线程默认继承父线程的 daemon 状态。这意味着：从一个守护线程里 new 出的子线程，生下来就是守护线程——哪怕你本意是让它干正事。
- 常见陷阱：用守护线程做定时调度器（如每秒拉一次配置），它 spawn 的实际任务线程全是守护的 → 主程序一结束，所有任务线程被 JVM 强制终止，任务无声消失
- 解决办法：在创建关键子线程时显式重置：Thread task = new Thread(runnable); task.setDaemon(false); task.start();
- 主线程默认非守护，但它也能被改成守护线程（Thread.currentThread().setDaemon(true)），改完就失去“锚点”作用，极易导致 JVM 零延迟退出
JVM 退出时，守护线程不给你留余地
它不是优雅停机，而是“断电式终止”：不触发 finally、不运行 shutdown hook、不走 uncaught exception handler。栈帧直接回收，就像进程被 kill -9。
- 别在守护线程里写 try-finally 关闭文件或 socket —— finally 很可能永不执行
- Runtime.addShutdownHook() 注册的钩子本身必须是非守护线程，否则根本不会被调用
- 验证方式：加一句 System.out.println("Is daemon? " + Thread.currentThread().isDaemon());，运行时确认身份
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
