System.exit()会强制终止整个JVM，中断所有线程、跳过finally和资源清理、不等待异步操作，仅主线程调用并配合shutdown hook才是安全退出方式。
System.exit() 会立刻终止整个 JVM，不是只退出当前线程。 它不区分主线程还是子线程，只要任意一个线程调用了它，所有线程——包括正在运行的、阻塞的、等待中的，甚至 GC 线程和守护线程——都会被强制中断，进程随即退出。
它到底做了什么？
这不是普通的控制流跳转，而是 JVM 层面的“硬关机”指令：
- 直接停止所有线程调度，不给任何线程继续执行的机会；
- 跳过当前方法栈中所有未执行的
finally块、try-with-resources的自动关闭逻辑； - 不会等待异步操作完成，比如网络请求回调、数据库事务提交、日志缓冲刷盘；
- 即使注册了
Runtime.addShutdownHook()，也只在 exit 调用后才启动钩子——但如果多个线程竞争调用 exit，钩子可能根本来不及运行。
多线程场景下的典型风险
在并发环境下，System.exit 往往放大问题的破坏性：
- 服务端：某个线程在校验红黑树结构失败时调用 exit，整个微服务实例瞬间宕机，可能触发下游雪崩；
- Android：Binder 回调里执行 exit(1)，Activity 进程立即消失，
onDestroy()、ContentProvider.shutdown()全部跳过，用户看到闪退； - 测试环境：单元测试中某线程因数组越界调用 exit，JUnit 进程中断，无法输出失败堆栈，掩盖真实 bug。
更合理的替代方式
数据结构或业务逻辑中遇到异常或终止条件，应交由上层统一决策，而不是自行“拔电源”：
- 返回特殊值：如
null、Optional.empty()、-1（查找失败）； - 抛出受检异常：如
throw new NoSuchElementException("Node not found")，让调用方决定重试、降级或记录； - 使用状态封装对象：如
TraversalResult.success(data)或.failure("cycle detected")，兼顾结果与上下文。
如果真要退出，该怎么收尾？
极少数必须退出的场景（如初始化失败、严重配置错误），建议：
- 仅在主线程中调用，避免多线程竞争；
- 提前注册 shutdown hook 做关键资源清理（如关闭连接池、写入临时状态）；
- 确保 exit 前已处理完所有可预见的异常，不依赖 finally 做核心释放；
- 选用语义明确的状态码：0 表示正常结束，非零值（如 1、22）对应具体错误类型，便于运维排查。
