System.exit()会直接终止JVM，finally块完全不执行；这是JVM规范行为，控制权瞬间交还操作系统，所有未完成字节码（包括finally）均被丢弃。
System.exit() 会直接终止 JVM 进程，此时 finally 块**完全不会执行**。这不是“可能跳过”，而是 JVM 层面的硬性中断——控制权瞬间交还操作系统，所有尚未完成的 Java 字节码（包括已进入但未执行完的 finally）全部丢弃。
System.exit() 的本质是进程级退出
它不是抛异常、也不是 return，而是向操作系统发送 kill 信号级别的指令。JVM 收到后立即释放堆内存、关闭线程、卸载类加载器，不走任何 Java 层清理流程。
- 哪怕 finally 里只有一行日志打印或资源 close() 调用，只要 System.exit() 在 try 或 catch 中被执行，该行代码就永无机会运行
- 即使 System.exit() 出现在 try 块最后一行，JVM 也不会“先执行完这一行再退出”——它在执行到这一指令时就中止了整个虚拟机
- 与之对比：return、throw、break 等都属于 Java 控制流语句，JVM 会按规范保障 finally 执行；System.exit() 则绕过了这套机制
常见误解澄清
有人认为“只要进了 try 就一定进 finally”，这个前提在 System.exit() 面前不成立。关键不在“是否进入 try”，而在于“JVM 是否还存活”。一旦 exit 触发，整个执行上下文被销毁。
- 不是 finally “来不及执行”，而是 JVM 已经没有“执行”的能力了
- 不同于未捕获异常（finally 仍会执行后再向上抛）、也不同于 return（finally 在返回值暂存后执行），exit 是彻底清零
- Java 规范明确将 System.exit() 列为 finally 的标准例外场景，不是 bug，是设计使然
替代方案：安全退出应走正常流程
若需在退出前做清理，不要依赖 System.exit() + finally 的组合。正确做法是：
- 用 return 从 main 方法自然退出，让 finally 正常触发
- 把清理逻辑显式写在 exit 调用之前，例如 close()、flush()、log() 等操作放在 System.exit() 上一行
- 对关键资源（如文件句柄、数据库连接），优先使用 try-with-resources，它不依赖 finally 的执行时机，而是在作用域结束时由编译器插入 close 调用
- 避免在库方法或中间层调用 System.exit()，应将退出决策上收至顶层入口，便于统一管控
其他真正跳过 finally 的情况
除 System.exit() 外，以下情形也会导致 finally 不执行，原理类似——JVM 失去调度能力：
- JVM 崩溃（如 OutOfMemoryError 导致 native crash、Segmentation Fault）
- 操作系统强制 kill 进程（如 kill -9）
- 硬件故障（断电、宕机）
- 死循环或无限阻塞导致程序卡死，永远无法到达 finally 所在位置
