JVM 不等守护线程，所有用户线程结束即强制终止其运行；它无生命周期主权，不执行 finally，适合无状态可中断任务，虚拟线程默认为守护线程且不可更改。
Java 中守护线程的退出机制，核心就一句话：JVM 不等它，只要所有用户线程结束，守护线程立刻被强制终止。
守护线程的“依附性”本质
守护线程不是独立存活的线程，它没有自己的生命周期主权。它的存在前提是——有用户线程在运行。一旦 JVM 检测到所有非守护线程（包括 main 线程）都已终止，就会立即触发进程退出流程，此时所有正在运行的守护线程会被直接中断，不给任何执行机会。
- GC 线程、JIT 编译线程、信号处理线程等 JVM 内置线程都是守护线程，它们只为用户线程服务
- 你手动创建的线程，如果不显式调用 setDaemon(true)，默认就是用户线程
- 线程的 daemon 属性是继承的：在用户线程里 new 出的子线程，默认也是用户线程；在守护线程里 new 的，则默认是守护线程
为什么 finally 块可能不执行
这是最容易踩坑的地方。因为守护线程是被 JVM 强制杀死的，不是自然执行完 run() 方法退出的，所以即使代码里写了 try-finally，只要 JVM 开始退出，finally 中的逻辑大概率不会运行。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 比如在守护线程中打开文件、连接数据库、写日志，指望 finally 关闭资源——这不可靠
- 守护线程适合做无状态、可中断、无需清理的任务，例如心跳上报、监控采样、缓存预热
- 若必须做资源清理，应把关键逻辑放在用户线程中，或由用户线程主动控制守护线程的关闭
虚拟线程也遵循这个规则
从 Java 21 开始，Thread.ofVirtual() 创建的虚拟线程默认就是守护线程，且无法通过 setDaemon(false) 改为用户线程。这意味着：
立即学习“Java免费学习笔记（深入）”；
- 如果只启动虚拟线程而没有其他用户线程，main 结束后 JVM 立即退出，虚拟线程任务被截断
- Spring Boot 3.2+ 提供 spring.main.keep-alive=true，就是靠启动一个空转的用户线程来“拖住”JVM，让虚拟线程有机会跑完
- 自己写非 Web 应用时，若依赖虚拟线程完成任务，需手动加一个用户线程阻塞（如 Thread.sleep(Long.MAX_VALUE)），否则任务大概率执行不完
如何验证守护线程是否真的被强制终止
写个简单测试就能直观看到效果：
- 新建一个无限循环的线程，设置为守护线程，再让 main 线程 sleep 100ms 后结束
- 循环体里加一句打印，比如 System.out.println("working...")
- 实际运行你会发现：最多输出一两次，甚至一次都不输出，程序就结束了
- 对比用户线程版本：main 结束后，该线程会一直打印，直到你手动杀进程
