守护线程在最后一个非守护线程结束时被JVM强制终止，不执行finally、不释放锁、不保证I/O中断唤醒；仅适用于可丢弃的轻量后台任务，不可用于关键逻辑或资源释放。
守护线程和普通线程的终止时机差异
Java 程序退出时，JVM 只等非守护线程（即用户线程）全部结束；只要还有任意一个非守护线程在运行，JVM 就不会退出——哪怕所有守护线程都已死掉。反过来，一旦最后一个非守护线程结束，JVM 立刻终止，正在运行的守护线程会被强制中断，不执行 finally 块、不触发清理逻辑。
这决定了守护线程只适合做“辅助性后台任务”，比如日志刷盘、监控上报、连接保活心跳。它不能承担关键业务逻辑，也不能依赖其完成资源释放。
- 调用
thread.setDaemon(true)必须在thread.start()之前，否则抛IllegalThreadStateException -
main线程默认是非守护线程；所有由它直接创建的线程，默认继承其守护状态（即默认非守护） - 守护线程创建的子线程，默认也是守护线程——这个继承关系容易被忽略
如何判断一个线程是不是守护线程
用 thread.isDaemon() 即可，返回 true 表示是守护线程。但要注意：这个值只反映线程启动前的设置状态，无法反映 JVM 是否已开始强制终止它。
常见误判场景：在守护线程里打印 isDaemon() 结果为 true，就以为“它还能稳稳跑完”，其实 JVM 可能在任意指令点直接 kill 它——没有“优雅终止”保障。
立即学习“Java免费学习笔记（深入）”；
- 不要在守护线程中做阻塞式 I/O（如
socket.read()），因为中断可能不唤醒该操作，导致线程卡住不退出 - 避免在守护线程中使用
synchronized块长期持锁，JVM 强制终止时不会释放锁，可能引发其他线程死锁 - 若需观察线程状态，优先用
thread.getState()，而非仅靠isDaemon()推断生命周期
守护线程不适合做什么
它不是“后台常驻服务”的 Java 实现方案。凡是要求“必须做完”“必须释放资源”“必须通知外部系统”的任务，都不能交给守护线程。
典型反例包括：数据库连接池关闭、文件写入 flush、HTTP 请求回调等待、定时器任务（ScheduledExecutorService 中的任务若在守护线程池中执行，程序退出时会静默丢弃）。
- Spring 的
@Scheduled默认走的是守护线程池（ThreadPoolTaskScheduler的setDaemon(true)），若没显式配置setWaitForTasksToCompleteOnShutdown(true)，应用关闭时定时任务会被直接砍掉 - Logback 的
AsyncAppender内部用守护线程刷日志，所以进程突然退出时，最后几条日志大概率丢失 - 自定义线程池（
ThreadPoolExecutor）若传入的ThreadFactory返回守护线程，则整个池子里的任务都不受“shutdown + awaitTermination”保护
守护线程的合理使用姿势
真正安全的用法，是把它当作“JVM 生命周期的影子”，只做轻量、可丢弃、无副作用的维护工作。
比如：定期检查某个静态缓存是否过期并清理；向本地监控 agent 发送当前线程数；在测试中模拟后台心跳防止测试线程提前退出。
- 用
Thread.ofVirtual().daemon().unstarted(runnable)（Java 21+）比手动 new Thread 更简洁，但语义不变 - 如果任务需要一定可靠性，宁可用
Runtime.addShutdownHook(new Thread(...))替代守护线程——钩子线程虽也受限于 JVM 终止窗口，但至少能确保执行一次 - 对第三方库启用守护线程模式前，务必查文档：Netty 的
EventLoopGroup、Kafka 的KafkaProducer内部线程是否可设为守护？多数不可，强行设会导致连接泄漏或消息丢失
守护线程真正的复杂点不在怎么开，而在“它什么时候会悄无声息地停”——这个时机完全不由你控制，只取决于其他线程是否还活着。一旦把关键逻辑塞进去，出问题时连日志都难抓。
