守护线程不会阻止JVM退出，只要所有非守护线程结束，JVM立即终止；其核心区别在于必须在start()前调用setDaemon(true)，且仅NEW状态下可设，设为守护后JVM不等待其完成，也不执行finally或shutdown hooks。
守护线程不会阻止JVM退出——只要所有非守护线程结束，JVM立刻终止，不管守护线程是否还在跑。
守护线程和普通线程最直观的区别在哪
区别就在 setDaemon(true) 这一行调用，而且必须在 start() 之前设置，否则抛 IllegalThreadStateException。一旦设为守护线程，它就彻底失去“话语权”：JVM不等它执行完，也不管它正写日志、刷缓存还是发心跳包。
- 普通线程（默认）：JVM会等它自然结束或被中断
- 守护线程：只服务其他线程，自身不能持有关键业务逻辑
- 主线程（main）默认是非守护的；它的子线程默认继承父线程的守护状态
什么时候该用守护线程
典型场景是后台支撑型任务：监控、日志异步刷盘、JMX心跳、GC辅助线程。它们存在的唯一目的是“让其他线程更好干活”，而不是完成某个独立业务目标。
- ✅ 适合：
new Thread(() -> { while (true) { logBuffer.flush(); Thread.sleep(1000); } }).setDaemon(true).start(); - ❌ 不适合：数据库连接池关闭、文件上传回调、消息确认应答——这些必须确保执行完毕
- ⚠️ 注意：Spring 的
@Async默认使用SimpleAsyncTaskExecutor，每次新建线程且非守护；如需守护行为，得配自定义ThreadPoolTaskExecutor并设setDaemon(true)
为什么 setDaemon(true) 放在 start() 后会报错
因为线程状态一旦进入 RUNNABLE 或 TERMINATED，JVM 就不再允许修改守护属性——这属于线程元信息的“只读窗口期”。底层实现上，Thread 对象初始化时有个 daemon 字段，仅在 NEW 状态下可写。
立即学习“Java免费学习笔记（深入）”；
- 错误写法：
t.start(); t.setDaemon(true);→ 抛IllegalThreadStateException - 正确顺序：
t.setDaemon(true); t.start(); - 调试技巧：用
t.getState()查状态，确认是NEW再设守护
JVM 退出时守护线程的真实行为
不是“被杀死”，而是直接终止执行，不触发 finally、不运行 shutdown hooks、不走 Thread.UncaughtExceptionHandler。它的栈帧被粗暴回收，就像拔电源。
- 所以别在守护线程里写
try-finally释放资源——finally很可能根本不执行 -
Runtime.addShutdownHook()注册的钩子本身必须是非守护线程，否则根本不会被调用 - HotSpot 中，JVM 检测退出的逻辑是：遍历所有线程，若只剩守护线程，立即调用
exit()
真正容易被忽略的是：守护线程的“后台性”完全依赖 JVM 生命周期，和操作系统进程无关；你用 nohup java -jar app.jar & 启动，照样会在所有用户线程结束后退出——它不等于 Linux 的 daemon 进程。
