java中finally块在jvm致命错误（如outofmemoryerror、stackoverflowerror、internalerror）时不会执行，因jvm已不稳定或失控，无法保证字节码执行；try-with-resources同理失效。
Java中无法在JVM致命错误（如OutOfMemoryError、StackOverflowError、InternalError等java.lang.Error子类）发生时，通过try-catch-finally或try-with-resources保证资源释放。
finally块对致命错误无效
finally块仅在JVM正常运行、线程未被强制终止的前提下执行。而致命错误意味着JVM已处于不稳定或不可恢复状态：
-
OutOfMemoryError（堆/元空间/直接内存耗尽）可能使JVM连分配异常对象或执行finally字节码的栈帧都失败； -
StackOverflowError会立即中断当前调用栈，finally根本无栈空间进入； -
InternalError或VirtualMachineError子类通常表示JVM内部崩溃，控制流已失控。
try-with-resources同样不适用
try-with-resources本质是编译器生成的finally逻辑（即自动插入资源关闭代码），它依赖JVM能完成字节码执行。一旦触发致命错误，该机制与手写finally一样失效——不会调用close()，也不会触发AutoCloseable契约。
可缓解但无法保证的实践
虽无法“保证”，但可通过以下方式降低风险：
-
使用显式资源生命周期管理：例如在连接池（HikariCP）、文件通道（
FileChannel）中启用超时和空闲回收，让资源在JVM崩溃前被外部机制清理； -
避免长生命周期资源持有：不长期缓存大对象或未关闭的流；优先用短作用域+
try-with-resources减少单次崩溃影响面； -
配置JVM参数主动防御：如
-XX:+ExitOnOutOfMemoryError快速终止进程，配合系统级监控（如systemd、supervisord）重启服务，比让JVM带病运行更利于资源回收； - 关键资源加操作系统级保障：如数据库连接用连接池自动重连，文件句柄由OS在进程退出时自动释放（Linux下所有fd都会被内核回收）。
不要依赖Shutdown Hook
Runtime.addShutdownHook在JVM正常关闭（如System.exit、信号SIGTERM）时有效，但对致命错误（尤其是kill -9或OOM崩溃）完全不触发——它本身就需要JVM有余力调度新线程。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
