Java中不能靠抛异常实现优雅退出，因为异常机制非流程控制工具，会掩盖错误、破坏调用栈、干扰监控；应使用System.exit(int)明确退出意图，或采用分层返回与外部信号协调。
Java里不能靠抛异常实现“优雅退出”——异常机制不是流程控制工具，强行用它退出程序会掩盖真实错误、破坏调用栈语义、让维护者摸不着头脑。
为什么throw new RuntimeException()不是优雅退出
有人在main方法末尾或关键路径上手动抛异常，以为能“干净终止”，实际这属于滥用：
- JVM收到未捕获异常时会打印堆栈并退出，但退出码默认是1，无法区分业务终止和真正崩溃
- 所有已注册的
ShutdownHook仍会执行，但此时资源可能已处于不一致状态（比如数据库连接被提前关闭） - 如果代码跑在容器或框架中（如Spring Boot），异常会被拦截、包装、记录，反而触发重试或健康检查失败
- IDE或监控系统看到大量
RuntimeException会误判为故障率飙升
真正可控的退出方式：用System.exit(int)
需要明确退出意图时，直接调用System.exit(int)——它跳过所有finally块和普通异常处理链，由JVM立即终止进程：
- 传0表示成功退出：
System.exit(0) - 传非0值（如1、255）表示异常终止，可被shell脚本或CI流水线识别
- 退出前仍会运行已注册的
Runtime.getRuntime().addShutdownHook()，适合做日志刷盘、连接释放等收尾工作 - 注意：Web容器（如Tomcat）中调用
System.exit()可能导致整个服务实例宕机，慎用
更优雅的替代方案：返回+外部协调
在可设计的场景下，避免进程级退出，改用分层返回值与外部信号配合：
- 命令行工具：main方法返回int，用
return 0;或return 1;（需将main改为public static int main(String[] args)不成立——Java不支持，所以实际仍得靠System.exit()，但逻辑上应把退出决策前置到业务层） - Spring Boot应用：监听
ApplicationStoppedEvent，或调用ConfigurableApplicationContext.close()，让框架按生命周期顺序关闭Bean - 长时间运行服务：通过文件、HTTP端点、JMX或信号（如SIGTERM）触发
System.exit()，而非在业务逻辑里硬编码 - 单元测试中模拟退出？用
SecurityManager限制System.exit()调用，或用SystemLambda库临时替换System.exit行为
异常该管的是“出错了怎么办”，不是“我要停了”。退出时机、退出原因、退出后清理——这些必须显式表达，而不是藏在一堆catch (Exception e) { throw new RuntimeException(e); }里。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
