system.exit()会立即终止jvm进程，finally块完全不执行；它是进程级硬终止，控制权瞬间交还操作系统，所有未完成字节码（包括finally）均被丢弃。

面试中问到 System.exit() 退出 JVM 时会发生什么，核心不是背语法，而是讲清“控制权移交”的本质——它不是 Java 层的流程控制，而是进程级的硬终止。

会立即中止 JVM，finally 完全不执行

哪怕 System.exit() 写在 try 块最后一行，JVM 也不会“执行完这行再退出”。它在字节码执行到该指令的瞬间，就放弃当前线程栈、丢弃所有未完成的 Java 操作（包括 finally、try-with-resources 的自动关闭、局部变量析构）。这不是“来不及”，而是 JVM 已无执行能力。

• 与 return、throw 有本质区别：后两者属于 Java 控制流，JVM 会保障 finally 执行；exit 绕过了整套机制
• Java 规范明确将其列为 finally 的标准例外场景，不是 bug，是设计使然

会运行 shutdown hook，但仅限已注册且未启动的

System.exit() 启动的是 JVM 的有序关闭流程：先暂停新任务，再并发执行所有已注册的 shutdown hook 线程，等它们全部结束才真正退出进程。

Java JDK 25

Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。

下载

• hook 中可做日志落盘、连接池优雅关闭、临时状态写入等轻量清理
• 多个 hook 无执行顺序保证，需自行处理线程安全
• 若某个 hook 阻塞（如死循环、IO 等待），整个 JVM 会卡住，看似“没退出”
• hook 里不能再调 System.exit()，否则未定义行为

不会触发任何 Java 生命周期方法

它不走应用容器或框架的生命周期管理路径。在 Web 场景下后果尤其严重：

• Tomcat 中调用 → 连接池未关闭、HTTP 请求被截断、事务未回滚、缓存未刷新
• Spring Boot 应用里执行 → @PreDestroy、DisposableBean.destroy() 全部跳过
• Android 中使用 → onDestroy()、ContentProvider.shutdown() 不执行，直接闪退

退出状态码有约定，但系统只认 0 和非 0

传入的 int 参数会被操作系统接收，用于判断程序是否“成功结束”：

• 状态码 0：惯例表示正常退出（非强制）
• 非 0 值（建议用 1–127）：表示某种错误类型，含义由你定义并文档化
• 负数或 >255 的值会被取模（如 System.exit(-1) 实际返回 255）
• 避免用 143：它常被 kill -15 占用，易造成信号混淆

不复杂但容易忽略：它不是退出方法，是拔电源。