System.exit()是JVM级强制终止，跳过finally、try-with-resources、shutdown hook等所有清理机制；仅适用于启动失败等极端场景，Web应用、库代码、多线程中绝对禁用。
System.exit() 不是“退出方法”，而是直接终结 JVM 进程。它跳过所有 Java 层控制流保障机制，包括 finally 块、try-with-resources 自动关闭、return 后续逻辑，甚至已注册但尚未执行完的 shutdown hook（若某个 hook 卡死，整个退出会挂住）。它适用于启动失败、配置崩溃、安全熔断等无法继续运行的极端场景，而非常规业务终止。
什么时候该用，什么时候绝对不能用
该用的情况很窄：
- main 方法中检测到严重初始化错误（如 license 校验失败、核心配置缺失）
- 命令行工具因参数非法必须立即中止（如
java MyApp -f nonexistent.txt） - 嵌入式或脚本化环境，需向 shell 明确返回码供后续判断（
$? == 0表示成功）
绝对禁用的场景：
- Web 应用（Spring Boot、Tomcat 等）的业务代码里——容器负责生命周期，你调用 exit 会干扰健康检查、优雅停机和资源回收
- 被其他模块 import 或依赖的库中——这会让调用方失去控制权，属于严重 API 设计缺陷
- 多线程环境中非主线程内调用——它杀的是整个 JVM，不是当前线程
exit code 怎么设才靠谱
状态码不是随便填的数字，它是给操作系统和外部流程看的契约：
- 只用 0–127 范围内的整数；避免负数（
System.exit(-1)在部分系统变成 255）、避免 143（与kill -15冲突） -
0：唯一表示“成功”或“正常终止”的值 -
1：通用错误，不推荐泛用；建议按语义细分，例如：2参数错误、3文件不可读、4网络连接失败 - 务必在项目文档中明确定义每个非零码含义，否则对运维和脚本无意义
想清理资源？别指望 finally
因为 System.exit() 触发后，finally 永远不会执行。常见误写：
try {
doSomething();
} finally {
cleanup(); // ← 这行永远不会运行
}
System.exit(1);
正确做法只有两种：
-
显式前置清理：把 close、flush、log 等关键操作写在
System.exit()调用之前 -
用 try-with-resources 管理可关闭资源：它由编译器保障在作用域结束时调用
close()，不依赖 JVM 退出路径
如果清理逻辑复杂或涉及异步/IO 阻塞，应改用 正常流程退出（如 return 主方法末尾），让 JVM 自然走完 finally 和 shutdown hook。
比 exit 更狠的选项：Runtime.halt()
Runtime.getRuntime().halt(int) 是 System.exit 的“核按钮”版本：
- 连 shutdown hook 都跳过，JVM 瞬间消失，不等待任何线程结束
- 不触发 SecurityManager 权限检查（如果还存在的话）
- 调试时 IDE 断点、JFR 事件、GC 日志全部中断，极难排查
它只应在 JVM 内部状态已损坏（如内存被篡改、类加载器崩溃）等理论上的“不可恢复”场景下考虑，生产代码、测试代码一律禁止使用。
