system.exit()与runtime.getruntime().exit()功能完全一致，前者是后者的静态封装，均触发jvm有序关闭序列（执行shutdown hook、finally块等）；真正关键区别在于system.exit()与runtime.getruntime().halt()：后者跳过所有清理步骤，属断电式强杀。
System.exit() 和 Runtime.getRuntime().exit() 功能完全一致，没有实质区别。前者是后者的静态封装，调用 System.exit(status) 时，内部直接转发为 Runtime.getRuntime().exit(status)，行为、参数含义、安全检查、关闭流程都一模一样。
为什么有两个看起来一样的方法？
System.exit() 是面向开发者的便捷入口：无需获取 Runtime 实例，直接调用即可，语义清晰，符合 Java 常用习惯。
Runtime.getRuntime().exit() 是底层实现入口：需先获取 Runtime 单例，再调用 exit()。它暴露了更底层的控制路径，但日常开发中极少需要绕过 System.exit() 直接使用。
两者都会触发 JVM 标准关闭序列：
- 并发执行所有已注册的 shutdown hook，并等待它们全部完成
- 若启用 runFinalizersOnExit（已废弃，不建议使用），则调用未执行的 finalize 方法
- 中断所有非守护线程，但允许当前线程中的 finally 块正常执行
- 最终以指定状态码退出 JVM
真正关键的对比是 System.exit() 与 Runtime.getRuntime().halt()
这不是“两个退出方法”的选择，而是“有序收尾”和“断电强杀”的根本区分：
- System.exit()：JVM 状态可信时的标准退出方式。适用于配置校验失败、初始化异常、用户主动退出等场景
- Runtime.getRuntime().halt()：跳过所有清理步骤，不执行 shutdown hook、不运行 finally、不调用 finalize、不等待线程。仅用于检测到 JVM 内部严重损坏（如内存非法覆写、类加载器崩溃）等极少数情况
Spring、Tomcat 等框架依赖 shutdown hook 完成连接释放、缓存刷盘、事务回滚等操作；滥用 halt() 会导致这些动作静默丢失，引发数据不一致或资源泄漏。
状态码怎么设才合理？
状态码本身不改变退出行为，只向外部环境（如 shell 脚本、容器平台）传递语义：
- 0：表示程序按预期逻辑终止，例如命令行工具成功完成任务
- 非0（如 1、2、127）：表示异常或非预期终止，例如参数错误、端口被占用、依赖服务不可达
- 避免随意使用负数或特殊值（如 -1），除非有明确约定；Shell 中通常只识别 0–255 范围
脚本中可通过 $? 获取上一个 Java 进程的退出码，据此做条件判断或重试策略。
多线程环境下要注意什么？
System.exit() 会立即中断所有非守护线程，但不保证它们能安全完成当前操作：
- 正在写文件的线程可能中断在 write() 中间，导致文件截断
- 持有数据库连接的线程被中断后，连接不会自动归还连接池
- 因此必须配合 shutdown hook 提前释放资源：关闭连接、刷新缓冲区、保存临时状态
- 不要在 shutdown hook 中执行耗时或阻塞操作（如网络请求），否则 System.exit() 会卡住等待
Runtime.halt() 在这种场景下更危险——它连 hook 都不给机会运行，所有清理逻辑直接失效。
