Java守护线程适合做不关键、可中断、不阻塞的后台支持工作，典型用途包括日志异步写入、心跳检测、缓存刷新、临时资源清理和运行时监控；但不可用于需可靠完成的任务，且须在start()前设setDaemon(true)，禁用阻塞I/O，不保证执行完成，不维护共享状态一致性，也不能替代优雅关闭逻辑。
Java 守护线程适合做“不关键、可中断、不阻塞”的后台支持工作，但绝不能用于需要可靠完成的任务。
典型使用场景
守护线程的核心价值在于轻量级、自动收尾的辅助服务。常见且合理的用途包括：
- 日志异步写入：将日志缓冲区内容定期刷盘或发往远程服务，主线程无需等待；任务中途终止不影响主流程，丢失少量日志可接受。
- 心跳检测与连接保活：在客户端维持长连接时，用守护线程定时发送 ping 包；主业务线程退出后，心跳自然停止，避免残留无效连接。
- 缓存预热或刷新：后台周期性加载热点数据到本地缓存；JVM 退出时未完成的刷新可丢弃，不影响系统一致性。
- 临时资源清理：监控并删除过期临时文件、清理内存中非关键缓存对象；程序关闭时未清理完的部分由系统自动兜底。
- 运行时监控采集：上报 CPU、堆内存、线程数等指标；采集中断不会导致应用故障，仅影响监控连续性。
关键限制条件
守护线程不是“省事万能线程”，以下约束必须严格遵守：
- 必须在 start() 前调用 setDaemon(true)：否则抛出 IllegalThreadStateException；设置后不可逆，也不能动态切换。
- 禁止执行不可中断的 I/O 操作：如阻塞式文件写入、socket 长连接读取；JVM 强制终止时可能留下未关闭句柄或损坏文件。
- 不保证任务执行完成：所有非守护线程一结束，JVM 立即退出，守护线程中的 finally 块、close() 调用都可能被跳过。
- 不能依赖共享状态的最终一致性：若守护线程修改了静态变量或全局缓存，而主线程恰好在此刻退出，这些变更可能丢失或处于中间态。
- 不适合替代优雅关闭逻辑：需显式释放资源（如数据库连接、文件锁、NIO Channel）的任务，应由用户线程主动管理，而非寄托于守护线程。
一个容易忽略的实践细节
守护线程继承父线程的 daemon 状态。如果在 Servlet 容器或 Spring 环境中启动新线程，主线程（如 Tomcat 的 worker 线程）本身可能是守护线程，此时 new Thread() 默认也是守护线程——这点常被误认为“线程是用户线程”，导致意外提前终止。
立即学习“Java免费学习笔记（深入）”；
替代方案建议
当任务需要可靠性时，优先考虑：
- 使用 ScheduledExecutorService 管理周期任务，并在 shutdown() 时调用 awaitTermination() 等待完成；
- 将清理逻辑注册为 JVM 关闭钩子（Runtime.addShutdownHook），它比守护线程更可控；
- 对关键 I/O 或网络操作，始终由主线程或明确管理的用户线程负责生命周期。
