system.exit()执行有序关闭，运行shutdown hook和finalize；runtime.getruntime().halt()直接强杀jvm，跳过所有清理步骤，不执行hook、finally或finalize。
System.exit() 和 Runtime.getRuntime().halt() 都能终止 JVM，但行为本质不同：前者是“有序收尾”，后者是“断电式强杀”。选错方法可能导致资源泄漏、数据丢失，甚至掩盖真实故障。
执行流程：清理 vs 归零
System.exit(status) 启动标准关闭序列：
- 按任意顺序并发执行所有已注册的 shutdown hook
- 等待这些 hook 全部完成（无超时）
- 若启用 runFinalizersOnExit，则运行未执行的 finalize 方法
- 最后真正退出 JVM
Runtime.getRuntime().halt(status) 完全跳过上述全部步骤：
- 不触发任何 shutdown hook
- 不执行任何 finally 块（即使当前线程正处在 try-finally 中）
- 不调用任何对象的 finalize 方法
- 不等待非守护线程，直接向 OS 发送 SIGKILL 级别信号（Linux 下等效于 kill -9）
多线程环境下的实际表现
在存在多个活跃线程时，二者行为差异尤为明显：
- System.exit() 会中断所有非守护线程，但先确保 shutdown hook 执行完毕；正在运行的用户线程可能被强制中断，但其 finally 块仍有机会执行
- Runtime.halt() 不区分线程类型，所有线程瞬间终止——包括正在写文件的 IO 线程、持有数据库连接的线程、甚至正在执行 shutdown hook 的线程本身
- 若 shutdown hook 内部有耗时操作（如上传日志、同步状态），System.exit() 会卡住等待；halt() 则无视它，直接消失
该用哪个？看故障可信度
选择依据不是“谁更快”，而是“JVM 是否还值得信任”：
- 优先用 System.exit()：配置校验失败、业务逻辑拒绝继续、用户主动退出等——JVM 状态完好，只需干净收场
- 慎用 Runtime.halt()：仅限检测到 JVM 内部严重不一致时，例如内存被非法覆写、类加载器链损坏、Unsafe 操作引发不可恢复的 native 崩溃迹象——此时执行 cleanup 可能导致二次崩溃或数据污染
注意：Spring、Tomcat 等框架内部均依赖 shutdown hook 实现优雅停机，滥用 halt() 会导致连接未关闭、缓存未刷盘、事务未回滚等静默故障。
一个容易被忽略的关键细节
System.exit() 在关闭序列已启动后再次调用，可能阻塞甚至失效（例如已有 hook 死锁）；而 halt() 总是立即生效——但它也意味着你放弃了最后一次诊断机会。生产环境若频繁触发 halt()，说明系统已进入“无法自愈”状态，应优先排查根本原因，而非依赖强杀兜底。
