守护线程用于执行非关键后台任务，不阻止JVM退出；适合日志刷盘、缓存清理、心跳上报等可中断、低优先级工作，但不可用于需保证完成或涉及外部资源释放的场景。
守护线程（Daemon Thread）在 Java 中主要用于执行后台支持性任务，它不会阻止 JVM 退出——当所有非守护线程结束时，JVM 自动终止，无论守护线程是否还在运行。它的核心价值在于“不干扰主流程生命周期”，适合做清理、监控、日志刷盘、心跳上报等轻量级、可中断的辅助工作。
定时日志刷盘与异步写入
很多日志框架（如 Log4j2、Logback 的异步 Appender）内部会启用守护线程，将日志缓冲区中的内容定期批量写入磁盘。这类任务不需要保证“100%完成”，即使 JVM 快速关闭，少量日志丢失也可接受；用守护线程能避免因日志线程未退出而拖住 JVM 关闭。
- 避免手动管理线程生命周期：无需在 shutdownHook 中显式 interrupt 或 awaitTermination
- 设置方式简单：thread.setDaemon(true)，且必须在 start() 前调用
- 注意不要在守护线程中执行阻塞 I/O 或长时间数据库操作，否则可能造成资源滞留
资源清理与缓存过期扫描
例如本地缓存（如 Caffeine、Guava Cache）常依赖守护线程周期性扫描并驱逐过期条目；又如连接池维护空闲连接、清理已失效的 Socket 连接等。这些任务本质是“尽力而为”的后台维护，不参与业务逻辑，也不应影响应用停机。
- 守护线程适合低频、非关键、可延迟执行的清理逻辑
- 若清理动作涉及外部系统（如远程服务注销），建议改用 Shutdown Hook + 显式等待，确保可靠性
- 避免与主线程共享未加锁的可变状态，防止并发修改导致状态不一致
健康监控与心跳上报
微服务中常有守护线程定时向注册中心（如 Nacos、Eureka）发送心跳，或采集 JVM 内存、GC、线程数等指标推送到监控系统。这类任务需要持续运行，但一旦主服务下线，心跳自然停止也无妨——注册中心本身具备超时剔除机制。
- 心跳间隔通常设为秒级（如 5~30 秒），不宜过短增加注册中心压力
- 网络失败时应静默重试，不抛出未捕获异常，否则可能导致线程意外终止
- 不建议在守护线程中执行同步 HTTP 调用并设置长超时，容易阻塞并掩盖真实问题
避免误用：哪些场景不该用守护线程
守护线程不是“后台线程”的万能解。以下情况应使用普通线程 + 显式生命周期管理：
- 需确保执行完成的任务（如关闭前保存用户会话、提交事务日志）
- 涉及外部资源释放
（如关闭数据库连接池、释放文件句柄），必须可控、可等待
- 任务失败需告警或补偿（如消息重发、对账修复），守护线程崩溃不易感知
- 与 Spring Bean 生命周期耦合的任务（如 @PostConstruct 启动、@PreDestroy 销毁），应交由容器统一管理
守护线程是轻量后台任务的合适载体，关键在理解其“随 JVM 生灭”的语义边界。设计时先问一句：这个任务没做完，是否会影响系统正确性？如果答案是否定的，那它很可能适合放进守护线程里。
