守护线程不适合承担资源清理任务，jvm退出时不等待其执行close/flush/shutdown等操作，文件句柄、数据库连接、socket等资源极可能未释放；子线程继承守护属性会放大风险；应仅用于纯内存计算或异步日志，关键清理须由用户线程或shutdown hook完成。
守护线程不适合承担资源清理任务，这是它最易被误用的关键点。JVM 退出时不会等待守护线程执行完任何逻辑，包括 close()、flush() 或 shutdown() 等操作，资源极可能处于未释放状态。
不能依赖守护线程做显式资源释放
文件句柄、数据库连接、网络套接字、内存映射等资源，必须由用户线程在退出前主动释放。守护线程中若打开 FileOutputStream 或建立 Socket 连接，JVM 终止时这些资源会被强制丢弃，导致：
- 临时文件残留或写入不完整
- 数据库连接池泄漏，影响后续启动
- 端口未释放，重启时报 Address already in use
- 外部服务收不到优雅下线通知
子线程继承守护属性，连锁风险放大
如果在守护线程里 new Thread(() -> { /* 打开文件 */ }).start()，这个新线程默认也是守护线程——它同样无法保证执行完 finally 块或 try-with-resources 的自动关闭。整个后台任务链都失去资源安全兜底能力。
轻量无状态是基本要求
守护线程应避免持有任何需手动管理的资源。推荐做法是：
- 只做纯内存计算、日志打点（使用异步日志框架如 Logback 的 AsyncAppender）
- 用 volatile 标志位控制循环，配合 Thread.interrupted() 响应中断
- 绝对不调用阻塞 IO 方法（如 FileInputStream.read()），更不封装成 try-catch-finally 形式来“假装”能清理
真正需要清理时，交给用户线程统一处理
标准做法是在 main 或业务线程结束前，显式触发 shutdown 钩子：
- 注册 Runtime.getRuntime().addShutdownHook(new Thread(() -> { /* 关闭连接、刷盘、注销服务 */ }))
- 使用 ExecutorService 的 shutdown() + awaitTermination()
- Spring 中通过 @PreDestroy 或 DisposableBean 接口完成 Bean 级清理
守护线程只负责“服务”，不负责“收尾”。该谁的事，就该谁干。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
