守护线程是JVM随从，主人退出即终止，不执行清理；任务若不可丢（如事务回调、连接池关闭）绝不能放其中，须改用用户线程+volatile控制+interrupt+join+可选shutdown hook。
守护线程不是“后台慢任务的保险箱”，而是 JVM 的“随从”——主人一走，它立刻消失，不打招呼、不收尾、不善后。所谓“长周期同步任务被强行掐断”，本质是把本该由用户线程保障的任务，错误交给了守护线程来扛。
明确任务性质：它丢得起吗？
判断一个任务能否放进守护线程，只看一条：中途被硬杀，系统是否仍一致、可用、无数据错乱？
- 能丢：日志异步刷盘（丢了最后几条不影响业务）、JMX心跳上报（断一秒无感知）
- 不能丢：数据库连接池关闭（不关会导致连接泄漏）、文件上传完成确认（漏发导致客户端以为失败）、事务提交后回调（不执行会丢失业务状态）
只要答案是“不能丢”，就绝不能放守护线程里——这不是优化，是埋雷。
改用可控制生命周期的用户线程 + 显式终止机制
把任务移到普通线程中，自己掌握启停节奏：
- 用 volatile boolean running 控制循环退出，主线程退出前设为 false
- 配合 thread.interrupt() 中断阻塞调用（如 sleep、wait、queue.take）
- 在 run() 中捕获 InterruptedException，并主动执行清理逻辑（close socket、flush buffer、commit 等）
- 调用 thread.join(timeout) 等待优雅结束，超时则记录警告
必要时搭配 shutdown hook 做兜底（但别依赖它）
钩子只响应 System.exit()、Ctrl+C 或 kill -15，对 kill -9 完全无效，且不能访问守护线程内部状态。若要用：
- 确保钩子本身是非守护线程（默认就是）
- 只做轻量级、无依赖的最终动作：比如强制 flush 全局日志缓冲区、标记临时文件为废弃
- 绝不在线程内读写守护线程的局部变量或未同步的 volatile 字段
- 钩子里避免 IO、网络、锁竞争等耗时操作
启动顺序和状态验证不能省
setDaemon(true) 必须在 start() 之前调用，否则抛异常；而且只能设一次。调试时加一句：
System.out.println("Thread is daemon: " + t.isDaemon());
或者用 t.getState() 确认线程处于 NEW 状态再设属性，避免误判。
