守护线程会在主线程退出时被强制终止，不保证执行完；JVM 仅等待非守护线程结束，守护线程可能被立即杀死，不执行 finally、shutdown hooks 或资源释放逻辑。
守护线程会在主线程退出时被强制终止，不保证执行完
Java 中的 Thread 设置为守护线程后，JVM 会把它当作“辅助角色”——只要所有非守护线程（包括 main 线程）都结束了，JVM 就直接退出，不管守护线程正在干啥。它不会等 run() 执行完，也不会触发 finally 块，更不会调用 shutdown hooks。
常见错误现象：
• 启动一个守护线程去写日志、刷缓存或发送心跳，结果程序一闪就退出，文件没写完、网络请求根本没发出去
• 在守护线程里加了 System.out.println("done") 和 finally { System.out.println("cleanup") }，但什么都没打印
- 必须在
start()之前调用setDaemon(true)，否则抛IllegalThreadStateException - 主线程 sleep 或手动
join()守护线程是常见补救手段，但本质是“不让 JVM 退出”，不是“让守护线程安全结束” -
main线程本身默认是非守护的；一旦它跑完main()方法体，就算没有显式调用System.exit()，JVM 也会开始收尾
如何判断一个线程是不是守护线程
运行时用 isDaemon() 查，但要注意：这个值只反映创建后的状态，不能反推行为。比如你看到 thread.isDaemon() == true，只能说明它被设过守护，不代表它当前一定还在跑——可能已经被 JVM 杀掉了。
- 调试时别只看
isDaemon()，配合getState()观察是否已进入TERMINATED - 不要在守护线程里依赖
isDaemon()做逻辑分支，它和“是否还活着”没有因果关系 - 线程池里的工作线程默认继承创建它的线程的守护状态，所以
Executors.newCachedThreadPool()创建的池，若在守护线程里调用，整个池都可能是守护的（容易踩坑）
守护线程适合做什么，不适合做什么
适合做无状态、可中断、不涉及资源释放的后台任务：比如定时采样 GC 数据、轮询某个标志位、维持连接保活（前提是上层协议允许突然断连）。
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
立即学习“Java免费学习笔记（深入）”；
不适合做任何需要可靠完成的事：比如关闭数据库连接、删除临时文件、提交事务、发送关键告警。
- 适合：
new Thread(() -> { while (!shutdown) { logStats(); Thread.sleep(5000); } }).setDaemon(true); - 不适合：
new Thread(() -> { try (FileWriter w = new FileWriter("log.txt")) { w.write("final msg"); } }).setDaemon(true);——try-with-resources根本不会执行 - 如果要用线程做清理，必须是非守护线程 + 显式生命周期管理（如
Runtime.addShutdownHook()）
JVM 退出时机比想象中更早
很多人以为“主线程退出=main方法执行完”，其实 JVM 是看“有没有非守护线程在运行”。哪怕你在 main() 最后一行启动了一个非守护线程并立即 return，JVM 也会继续运行，直到那个线程也结束。
-
System.exit(0)会立刻终止所有线程，包括非守护线程，此时守护线程的行为无关紧要 - 使用
java -Dfile.encoding=UTF-8 MyApp这类参数不影响守护线程语义，但会影响其内部 I/O 行为（比如日志乱码），容易误判为“线程挂了” - 在容器环境（如 Docker）中，如果主进程是 Java 应用，且它只靠守护线程维持，容器可能秒退——因为 JVM 认为自己没事可干了
最常被忽略的一点：守护线程的 run() 方法里哪怕只有两行代码，也可能只执行了第一行就被终结。它没有“最后一点时间”的概念。
