System.exit 不能用于实现“异常退出逻辑”，它只是强制终止 JVM，不区分正常或异常场景；真正应通过抛出和捕获异常、返回码等方式表达错误，仅在独立 CLI 工具中谨慎使用并确保资源清理。
System.exit 不能用于实现“异常退出逻辑”，它只是强制终止 JVM，不区分正常或异常场景。真正需要的是合理抛出异常、捕获处理、或通过返回码表达错误状态，而不是依赖 System.exit 来模拟异常行为。
理解 System.exit 的本质
System.exit(int status) 会立即停止当前 JVM 进程，跳过所有 try-finally 块、未执行的 shutdown hook（除非已注册并触发）、以及后续代码。它不是异常机制的一部分，也不抛出任何 Throwable。status 为 0 表示正常终止；非 0（如 1）常被操作系统解释为异常退出，但这只是约定，JVM 本身不校验或赋予语义。
- 调用 System.exit 后，finally 中的资源清理（如 close()）不会执行——除非你提前手动处理
- 在 Web 应用、Spring Boot 或单元测试中滥用 System.exit 可能导致容器挂起、测试中断或服务不可用
- 它无法被 catch（Throwable e），因为不经过异常传播链
替代方案：用异常表达错误意图
Java 的异常机制才是表达“异常退出逻辑”的正确方式。该抛就抛，该捕获就捕获，让调用方决定是否终止程序。
- 业务逻辑中遇到非法参数、数据缺失、外部服务不可用等，应 throw IllegalArgumentException、IOException 等受检或非受检异常
- 主方法（main）可捕获顶层异常，并根据需要打印堆栈、记录日志，再决定是否调用 System.exit（仅限命令行工具等单机场景）
- 例如：throw new IllegalStateException("配置文件加载失败") 比 System.exit(1) 更利于模块复用和测试
必要时安全使用 System.exit 的场景与写法
仅在明确需要进程级退出的独立 CLI 工具中，且必须确保关键清理已完成，才考虑 System.exit。
立即学习“Java免费学习笔记（深入）”；
- 先关闭资源：显式关闭 Scanner、FileWriter、数据库连接等
- 可注册 shutdown hook 处理异步清理（但不能依赖它做关键事务）
- main 方法中统一出口：把 exit 调用集中到一处，避免分散在多处
- 示例：System.exit(parseArgs(args) ? runApp() : 2); —— 返回不同状态码便于脚本判断
避免常见误用
很多开发者误把 System.exit 当作“快速终止错误流程”的捷径，结果破坏了程序结构和可维护性。
- 不要在库代码、service 方法、监听器回调里调用 System.exit —— 这会让调用方失控
- 不要用它代替 return 或 break；循环/方法内直接 exit 会让逻辑难以追踪
- 单元测试中若触发 System.exit，需用 SecurityManager 或 mock（如 SystemExitSecurityManager）拦截，否则测试会直接退出
