system.exit()会立即终止整个jvm，强制结束所有线程，跳过try-catch-finally、shutdown hook等机制，导致资源泄漏和状态丢失；仅适用于启动阶段致命错误，多线程应采用协作式关闭。
System.exit() 会立刻终止整个 JVM，所有线程无一例外全部结束，它不是“退出当前线程”，也不是“退出某个模块”，而是直接向操作系统发出进程终结信号。这个动作跳过 Java 层几乎所有保障机制，包括 try-catch-finally、try-with-resources、return 后续语句，甚至已注册但尚未执行完的 shutdown hook（若某 hook 卡死，整个退出过程就会挂住）。
它对多线程的影响是全局且不可逆的
无论你在主线程、子线程、线程池任务、还是异步回调中调用 System.exit(0) 或 System.exit(1)，效果完全一致：
- 所有存活线程（包括守护线程和非守护线程）立即停止调度，不执行任何剩余字节码
- 线程本地变量、栈帧、未同步的 volatile 写入等状态全部丢失
- JVM 不等待线程自然退出，也不触发 Thread.stop() 或 interrupt() 流程
- 即使某个线程正持有锁、正在写文件、或处于 synchronized 块中，也会被硬中断
为什么它不适合常规多线程退出场景
多数多线程程序需要协调资源释放、状态持久化、日志刷盘等操作，而 System.exit() 完全绕过这些：
- 数据库连接不会 close，连接池可能泄漏连接
- 临时文件、内存映射文件、NIO Channel 不会 cleanup
- Log4j/SLF4J 的异步 Appender 缓冲区来不及 flush，日志丢失
- Spring Boot 的 @PreDestroy、DisposableBean、shutdown hook 全部失效
- Android 中 Activity、Service、BroadcastReceiver 等组件不会走正常销毁流程
真正该用它的极少数情况
仅限启动阶段发现致命错误、无法恢复的环境异常，且后续已无任何清理意义：
- JVM 启动参数严重错误（如 -Xmx 超出物理内存）
- 核心配置加载失败（如 license 校验失败、加密密钥损坏）
- 安全策略强制熔断（如检测到调试器注入、运行时篡改）
- Shell 脚本中依赖 exit code 做流程判断（如部署脚本验证失败后 abort）
多线程环境下更合理的替代方案
避免暴力终止，转向协作式关闭：
- 使用 volatile boolean shutdownRequested 控制线程循环退出条件
- 对线程池调用 shutdown() + awaitTermination() 等待任务完成
- 在 Android 中优先 finish() 当前 Activity，用 ActivityManager 管理栈，而非 System.exit()
- 在 Spring Boot 中用 SpringApplication.exit(ctx) 触发上下文关闭，再由容器决定是否调 System.exit()
- 必要时注册 shutdown hook 执行关键清理，但需确保其本身不阻塞、不抛异常
