守护线程不能依赖自动退出清理资源，必须由开发者主动控制；setdaemon(true)须在start()前调用，否则抛异常；禁止在守护线程中执行阻塞i/o；应使用volatile标志+循环检查实现可控退出；关键资源清理必须交由用户线程或shutdown hook兜底。
Java 中守护线程不能依赖“自动退出”来完成资源清理——它被 JVM 强制终止时，不会触发 finally 块、不会执行 shutdown hooks、也不会等待 I/O 关闭。真正安全的资源管理，必须由开发者主动控制，而不是交给 daemon 机制。
必须在 start() 前设置 setDaemon(true)
这是硬性约束。一旦线程已启动（进入 RUNNABLE 或更早状态），再调用 setDaemon(true) 会抛出 IllegalThreadStateException。常见错误是先 start 再设 daemon，导致设置失效，线程变成用户线程，意外阻止 JVM 退出。
正确写法：
- 创建 Thread 实例后立即调用
setDaemon(true) - 确认未调用
start()之前完成设置 - 若使用 Runnable + Thread 构造，可在 new 后链式调用：
new Thread(runnable).setDaemon(true).start();
禁止在守护线程中做阻塞型资源操作
文件写入、数据库提交、网络连接关闭等操作具有不确定性：守护线程可能在 write() 中途、close() 前一刻被 JVM 终止。此时文件损坏、连接泄漏、事务不完整都可能发生。
典型风险场景：
- 日志线程直接 FileOutputStream.write() → 日志截断或文件损坏
- 临时文件清理线程正在 delete() → 文件残留或权限异常
- 心跳发送线程卡在 socket.write() → 连接未优雅断开
替代方案：把 I/O 操作移出守护线程，改用带超时的同步队列 + 用户线程消费；或仅让守护线程触发清理信号，由主线程/钩子兜底执行。
用 volatile 标志 + 循环检查实现可控退出
守护线程应主动响应退出信号，而非无限循环等待 JVM 杀死。核心是引入一个 volatile boolean 控制变量，并在主业务逻辑中定期检查。
示例结构：
- 定义
private static volatile boolean running = true; - 守护线程 run() 中写
while (running) { /* 工作 */ } - 在程序正常退出前（如 main 结束前、ShutdownHook 中）设
running = false; - 配合
Thread.interrupt()处理 sleep/block 状态
这样能确保线程在被终止前有机会执行清理逻辑（如 flush 缓冲区、释放锁、注销监听器）。
关键资源必须由用户线程或 JVM 钩子兜底
JVM 不保证守护线程的 finally 执行，也不运行 shutdown hook 中的守护线程。因此，真正需要保障的资源释放，必须交由用户线程或显式注册的 shutdown hook 完成。
- 注册 shutdown hook：用
Runtime.getRuntime().addShutdownHook(new Thread(() -> { /* 清理代码 */ })) - 确保该 hook 线程是用户线程（默认就是），且在 main 或其他用户线程退出前注册
- hook 中可安全调用
executor.shutdownNow()、fileChannel.close()、connection.close()等 - 避免在 hook 中启动新守护线程——它大概率来不及执行
例如：数据库连接池关闭、NIO Selector 关闭、本地内存映射释放，都应在 shutdown hook 中完成，而非依赖守护线程自身逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
