system.exit()会立即终止整个jvm，强制中断所有线程、跳过finally/try-with-resources/finalize等清理逻辑，仅shutdown hook可执行但不保证完成，严禁在web应用、库代码及多线程业务中使用。
System.exit() 会立刻终止整个 JVM，所有线程——无论是否已启动、正在运行或处于阻塞状态——全部强制退出。它不是“通知线程结束”，而是直接切断进程生命线，线程根本没机会响应或清理。
所有线程同步消失，不区分主次
调用 System.exit() 后：
- 主线程（main）立即停止，后续代码不再执行；
- 已 start() 的子线程（包括守护线程和用户线程）瞬间中断，无任何回调或 finally 执行机会；
- 线程池中的工作线程被强制终止，任务队列中待处理任务丢失，正在执行的任务戛然而止；
- 即使线程正持有锁、写入文件或发送网络请求，也会被硬性打断，可能造成数据不一致或资源残留。
finally、try-with-resources、析构逻辑全被跳过
Java 的异常处理与资源管理机制依赖线程正常退出路径。但 System.exit() 绕过所有控制流：
- try-catch-finally 中的 finally 块不会执行；
- try-with-resources 自动调用 close() 的保障失效；
- 对象的 finalize() 方法（如已启用）不会被调用；
- ThreadLocal 变量不会自动清理，可能引发内存泄漏（尤其在线程复用场景如 Tomcat 或线程池中）。
Shutdown Hook 是唯一可控的收尾时机
JVM 在真正退出前，会按注册顺序执行所有 shutdown hook 线程，这是唯一能插入清理逻辑的地方：
- 需通过
Runtime.getRuntime().addShutdownHook(new Thread(() -> {...}))提前注册； - hook 线程本身也受超时限制（JVM 不等待长时间阻塞），且无法保证执行完成；
- 若
System.exit()发生在多线程竞争中（如并发调用），部分 hook 可能根本来不及启动。
典型误用场景与后果
在实际开发中，以下做法风险极高：
- 在 Android Service 的 onHandleIntent 或 Binder 回调里调用
System.exit()→ Activity 进程闪退，onDestroy() 不触发，数据库连接未关闭； - 在红黑树校验失败或图遍历检测到环时直接 exit → 微服务实例整机宕机，下游请求全部失败；
- 单元测试中用
System.exit()模拟错误 → JUnit 进程中断，测试报告缺失、覆盖率统计失效； - 在 Web 应用 Filter 或 Servlet 中调用 → 容器线程池被污染，后续请求可能复用未清理的线程上下文。
