finally不会运行，因为system.exit(0)直接终止jvm，跳过所有未执行字节码（包括finally），这是jvm规范行为，非bug。
finally 为什么没运行——System.exit(0) 直接终止 JVM
当 System.exit(0) 出现在 try 或 catch 块中，finally 块几乎必然跳过执行。这不是 bug，而是 JVM 规范行为：该调用会立即触发虚拟机退出流程，所有未完成的字节码（包括 finally 中的指令）都会被丢弃。
常见错误现象：try { log("start"); System.exit(0); } finally { log("cleanup"); } —— “cleanup” 永远不会打印。
-
System.exit(int)的参数值不影响行为，System.exit(1)同样跳过finally - 即使
finally里有资源释放逻辑（如file.close()），也会失效，可能造成句柄泄漏 - 在单元测试中容易误判——你以为资源已清理，实际没有
哪些操作会让 finally 彻底失能
除了 System.exit()，还有几种极端情况会绕过 finally，它们共同点是“不经过正常控制流返回”。
-
Runtime.getRuntime().halt(int)：比exit()更暴力，连 shutdown hook 都不触发 - JVM 被外部信号强杀（如
kill -9、Windows 上的任务管理器结束进程） - 宿主机断电、内核 panic、容器被
docker kill --signal=SIGKILL终止 - 本地方法（JNI）中发生不可恢复的崩溃（如段错误），JVM 进程直接终止
注意：Thread.stop() 已废弃且不推荐，它虽可能跳过 finally，但行为不可靠，现代代码不应依赖或测试它。
立即学习“Java免费学习笔记（深入）”；
想确保清理逻辑执行？别只靠 finally
finally 是为「正常控制流中断」设计的，不是为「进程级终止」兜底。真要保障关键清理（如释放锁文件、通知下游服务、写入审计日志），得换思路。
- 用
Runtime.addShutdownHook(new Thread(() -> { /* cleanup */ }))，它能在exit()和大多数正常关闭场景中触发（但对halt()和kill -9无效） - 对必须持久化的状态，考虑把清理动作拆成「标记 + 异步补偿」：比如先写一个
.shutdowning标记文件，再由另一个守护进程定期扫描并补全清理 - 避免在
finally中做阻塞操作（如网络请求、长耗时 I/O），否则System.exit()等待超时后仍可能被强制中断，反而更难诊断
调试时怎么确认 finally 到底有没有跑
别只看日志——日志可能缓冲未刷出，尤其在 System.exit() 前。实操上更可靠的验证方式：
- 在
finally开头加System.err.println("in finally")并立刻System.err.flush()，stderr 默认不缓冲 - 用 JVM 参数
-XX:+PrintGCDetails或jstack抓取线程栈，确认是否卡在System.exit()调用点 - 在 IDE 调试模式下，在
finally第一行打条件断点：Thread.currentThread().getStackTrace()[0].getMethodName().equals("finally")（仅作演示，实际用法需调整）
最易被忽略的是：finally 里的异常如果未被捕获，会覆盖原异常，导致错误信息丢失。而 System.exit() 发生时，这种掩盖根本来不及发生——它压根没机会进到那行代码里。
