kill -9会强制终止jvm进程，finally块不会执行完毕甚至根本不执行；它跳过所有java层回调，包括shutdown hooks、finalize和jni卸载，属操作系统级硬切断，无法被java程序防御。
Java中finally块在执行期间遭遇操作系统Kill信号（如kill -9），会立即中断整个JVM进程，finally代码块**不会执行完毕，甚至可能根本没开始执行**——这不是异常，而是进程级强制终止，Java虚拟机已无机会调度任何字节码。
kill -9 直接终结JVM运行时上下文
当Linux或Unix系统向Java进程发送SIGKILL（即kill -9 <pid></pid>）时：
- JVM进程被内核无条件终止，不触发任何Java层回调
- 当前线程堆栈、锁状态、本地方法调用全部丢弃
- 哪怕finally块已进入、正执行到
file.close()第3行，也会瞬间中断，无日志、无堆栈、无通知 - shutdown hook、finalize方法、JNI OnUnload等均不运行
与System.exit()的本质区别
System.exit()是JVM内部主动退出流程，仍会：
- 运行已注册的shutdown hooks
- 尝试完成当前正在执行的字节码（除非已到exit调用点）
- 保持线程安全语义（如synchronized块的释放）
而kill -9连JVM“知道自己要死”这个环节都跳过，属于操作系统层面的硬切断。
finally执行中被kill的真实后果
常见风险场景包括：
- 文件流未关闭 → 句柄泄漏，后续open失败
- 数据库连接未归还 → 连接池耗尽，新请求阻塞
- 临时文件未清理 → 磁盘空间持续增长
- 分布式锁未释放 → 其他节点长期等待超时
这些不是“finally没写对”，而是Java程序无法防御的外部中断。不能靠try-finally兜底，必须靠外部机制补偿。
应对思路：不依赖finally做关键保障
对强可靠性要求的操作，应组合使用以下策略：
- 资源类自身支持自动恢复或超时释放（如HikariCP连接空闲超时、Netty ChannelInactive事件）
- 关键状态写入持久化存储（如ZooKeeper临时节点、Redis带TTL的锁）
- 独立看门狗进程定期扫描异常残留（如检查/proc/
/fd下未关闭句柄） - 容器编排层配置preStop钩子，在kill前预留几秒优雅期（但
kill -9仍绕过）
finally仍是资源清理的第一道防线，但它只对Java控制流有效；面对kill -9这类信号，它天然失能。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
