system.exit()是jvm的“自毁指令”，立即终止整个进程，跳过所有清理逻辑；它不适用于web容器、android应用或测试框架，仅限main早期不可恢复错误且无异步依赖时谨慎使用。
System.exit() 不是退出按钮，而是 JVM 的“自毁指令”。它不协商、不等待、不清理，只要执行，整个进程立刻消失——无论你正在写日志、提交事务，还是在 Android 里播放音频。真正安全的退出，靠的是设计，不是一招“强制关门”。
别在 Web 应用或容器里调用 System.exit()
Tomcat、Spring Boot、Jetty 等容器本身负责启停和资源回收。你在业务代码里写 System.exit(0)，等于直接拔掉服务器电源：
- 连接池未关闭，数据库连接泄漏，后续请求全卡住
- HTTP 响应被截断，前端收到半包数据或超时
- 注册中心（如 Nacos）瞬间下线，触发负载均衡器剔除节点，引发雪崩
- 即使写在子线程里，也终止整个 JVM，不是只杀当前线程
排查方法：启动前加参数 -Djava.security.manager（JDK 17 前）或用字节码插桩工具（如 ByteBuddy）监控 exit 调用；生产环境建议 CI 阶段用 grep -r "System\.exit" ./src + SonarQube 规则自动拦截。
Android 里用它退出 App 是错觉
用户点“退出”按钮，系统本应走 Activity 栈退栈 + 进程后台保活逻辑。System.exit(0) 强行杀进程，后果很实在：
- onDestroy()、onPause() 等生命周期回调全跳过，UI 状态没保存
- Service 正在上传文件？中断后无重试，用户以为传成功了
- ContentProvider.shutdown() 不执行，数据库连接泄露
- 通知栏还在，但后台已死，点击直接崩溃
正确做法：对主 Activity 调用 finishAffinity() + System.exit(0) 仅作兜底（极少数场景），优先使用 moveTaskToBack(true) 让系统管理生命周期。
测试代码中慎用，尤其涉及多线程或框架
JUnit、TestNG、Spock 等测试框架依赖 JVM 正常结束来汇总结果、生成报告。System.exit() 会直接终结进程：
- @AfterEach / @AfterClass 清理逻辑不执行，临时文件、端口、MockServer 残留
- 多个测试类串行运行时，一个 exit 导致后续全部跳过
- CI 流水线误判为“构建成功”（因为 exit(0) 返回码是 0）
替代方案：抛出 AssertionError 或自定义异常让测试框架捕获；需提前终止时，用 return 或标志位控制流程，而不是杀 JVM。
真要用，必须满足三个硬条件
System.exit() 只适用于极少数不可恢复的启动失败场景，且必须同时满足：
- 发生在 main 方法早期：配置加载失败、端口被占、证书无效等，尚未初始化任何资源
- 退出码语义明确：用 0（成功）、1（通用错误）、2（参数错）、3（配置错）等，避开 143（SIGTERM）和负数
- 无异步依赖：没启动线程池、没注册 shutdown hook、没打开文件句柄——否则 cleanup 会被跳过
注意：Runtime.getRuntime().halt() 更危险，连 shutdown hook 都不执行，生产环境禁止出现。
