system.exit() 是 jvm 层面强制终止进程的指令，绕过 finally、shutdown hooks、spring boot 优雅停机等所有 java 安全机制；滥用会导致线程中断、资源泄漏、分布式状态不一致及系统级连锁故障；应仅在 main 启动失败时谨慎使用，流程控制中须改用异常或返回值。
因为 System.exit() 不是流程控制语句，而是 JVM 层面的进程终结指令——它不协商、不清理、不等待，直接向操作系统发起终止请求，所有线程（包括 GC 线程、日志线程、网络事件循环）瞬间中断，虚拟机进程被强制回收。
它绕过所有 Java 层保障机制
Java 的设计依赖一系列“安全网”来保证资源释放和状态一致性，而 System.exit() 会彻底跳过这些机制：
- finally 块和 try-with-resources：即使代码写在 finally 里，也不会执行；文件流、数据库连接、锁等无法自动关闭
- Runtime.addShutdownHook()：钩子虽已注册，但仅在 exit 调用后才尝试运行；若主线程已卡死或竞争激烈，钩子可能根本没机会触发
- Spring Boot 的优雅停机、Tomcat 的 contextDestroyed 回调、Netty 的 EventLoopGroup.shutdownGracefully()：全部失效，连接未关闭、事务未回滚、缓存未刷新
在流程控制分支中滥用后果更隐蔽也更严重
当开发者把 System.exit() 放在 if/else、循环体、回调函数或异常处理分支中，表面看只是“快速退出”，实则将不确定性注入整个运行时上下文：
- 一个 HTTP 请求处理中因参数校验失败调用 System.exit(1)，整台服务器进程消失，其他 200 个并发请求全丢
- 流式计算任务（如 Flink 或 Kafka Streams）在某个 record 处理分支中 exit，checkpoint barrier 断裂、watermark 滞后、状态快照丢失，后续恢复失败
- 多线程环境下，某子线程误触发 exit，主线程、定时器线程、心跳线程一并终结，监控失联、健康检查超时、负载均衡器立即剔除节点
高频退出会触发宿主机或虚拟化层保护
单次 exit 可能只影响当前进程，但在流程密集路径（如反压检测、序列号校验、限流熔断）中反复触发，会引发系统级连锁反应：
- Linux 内核持续回收 task_struct 和页表，调度开销飙升，vCPU 利用率虚高但有效吞吐归零
- 未释放的 socket、mmap 区域堆积，触发 OOM Killer，误杀 qemu-kvm 进程（退出码 137），整台虚拟机被强制终止
- VMware/ESXi 监控到 vmtoolsd 异常退出率突增，判定虚拟机不可信，主动 suspend 或 power off 实例
真正该做的不是“怎么安全地 exit”，而是“根本不该在这里 exit”
流程控制分支的职责是传递状态、抛出异常或返回信号，而非终结进程：
- 用 throw new IllegalArgumentException("invalid input") 让上层决定重试、降级或记录
- 返回 Optional.empty()、Result.failure("timeout") 或状态枚举（如 PROCESS_SKIPPED）
- 在命令行工具或极早期启动阶段（如 main 中配置加载失败）才考虑 exit，且必须限定为 0–127 范围内语义明确的状态码
