守护线程的 finally 不会执行，因为JVM退出时直接终止其上下文，不触发栈展开、shutdown hook或任何清理流程；其设计仅为服务非守护线程，生命周期完全依附于后者。
因为守护线程（Daemon Thread）本身不具备“自主生命周期”，它的存续完全依附于所有非守护线程是否存活。当 JVM 决定退出时，不会等待守护线程执行完 finally，而是直接终止其执行上下文。
守护线程被强制终止，不走任何 Java 清理流程
守护线程的设计初衷是为其他线程提供服务（如 GC、JIT 编译、日志刷盘等），它不是程序逻辑的“主体”。JVM 规范明确规定：一旦所有非守护线程（包括 main 线程）结束，JVM 就会立即中止所有守护线程，并直接退出进程——这个过程绕过栈展开、不触发 finally、不调用 shutdown hook、也不执行任何 try-catch-finally 的语义保障。
这意味着，哪怕守护线程正处在 try 块末尾、下一行就是 finally，只要此时 main 线程已 return 或 System.exit() 被调用，该 finally 就永无机会开始执行。
finally 失效不是“来不及”，而是 JVM 主动放弃调度
不同于 System.exit() 是主动发起进程级退出，守护线程终结属于 JVM 的“被动收尾”行为。它不发送中断信号，不抛出 ThreadDeath（该异常已被弃用且不可靠），也不做线程状态同步。底层实现上，HotSpot 会直接将守护线程的执行栈标记为废弃，调度器不再分配 CPU 时间片，线程状态瞬间变为 TERMINATED。
所以这不是“finally 没抢到执行权”，而是 JVM 根本没给它进入 finally 的机会——控制流尚未抵达，线程上下文已被销毁。
常见误判场景与验证方式
- main 中 sleep 后退出：main 执行完 sleep(5000)，未显式调用 System.exit()，但主线程自然结束 → 守护线程被立即 kill，finally 不打印
- 守护线程内含阻塞操作：如在 try 中调用 Object.wait() 或 LockSupport.park()，即使后续被 interrupt()，若未在 park 前检查中断状态，线程仍卡住，never 到达 finally
- 验证建议：在 finally 开头加 System.err.println("in daemon finally") + System.err.flush()；若无输出，基本可确认线程被静默终止
真正可靠的替代方案
- 关键清理逻辑不要放在守护线程的 finally 中，而应由非守护线程统一管控或通过 Runtime.addShutdownHook() 注册（注意：shutdown hook 对 kill -9 和 halt() 也无效，但能覆盖 exit() 和自然退出）
- 若必须由守护线程承担轻量清理，改用轮询 + volatile 标志位：在 run() 循环中定期检查 shutdownRequested，满足条件后主动 break 并执行 close/flush/log
- 资源类优先使用 try-with-resources，它由编译器生成字节码插入 close()，不依赖线程是否存活，也不经过 finally 语义链
