System.exit触发场景：什么时候需要手动终止程序

先说核心判断：手动终止程序这事儿，本来就不是常规操作。它更像是一种“断电式”兜底手段，而不是业务逻辑跑完后的自然收尾。只有当系统已经无法安全、可控地继续运行时，才需要主动切断 JVM 进程。问题是：什么时候才需要走到这一步？

启动阶段的致命错误

程序刚启动就发现了根本性缺陷，这种时候再让它跑下去，只会引来更混乱甚至更危险的状态。典型情况包括：

• 核心配置文件缺失，或者格式严重错误——比如数据库连接串为空、密钥解密失败，这种缺陷是没法通过后续逻辑来弥补的。
• License 校验失败或授权过期，法律或商业层面已经禁止运行，这时候继续提供服务就等于违规。
• 必需的本地资源不可用，比如指定端口被占用且无法更换，或者硬件设备初始化失败，程序连基本运行环境都搭建不起来。

命令行工具的明确失败

面向终端用户的 CLI 工具讲究的是快速反馈、干净退出，这样才能和 Shell 脚本的链式调用完美配合。如果遇到以下情况，直接退出的价值远大于硬撑：

• 用户传入非法参数——比如 ja va MyApp -i invalid-path.txt，而那个路径根本不存在，程序没必要继续往下走。
• 输入文件损坏或格式不支持，同时没有降级处理路径可以走。
• 执行动作需要 root 权限但当前未获得，且无法提示用户重试——与其卡在半路，不如直接报错退出。

嵌入式或容器化环境中的状态上报

在 Docker、Kubernetes 这类自动化部署流程里，退出码本身就是关键信号。平台会根据返回码来决定是重启、回滚还是报警。以下几种场景尤其需要非零退出码：

• 健康检查脚本验证失败，返回非零码触发容器重启。
• 数据迁移工具执行中途发现目标库结构冲突，且无法自动修复，与其让数据状态混乱，不如干净退出让运维介入。
• 插件或扩展模块加载失败，而宿主的策略明确要求“失败即退出”，而不是静默禁用某个功能。

绝对不该用 System.exit 的地方

下面这些场景如果调用了 System.exit()，往往不是解决问题，而是在制造更大的问题：

• Web 应用（Spring Boot、Tomcat、Jetty）的任意业务代码中——生命周期应该交给容器管理，业务代码擅自退出进程会破坏整个部署架构的设计。
• 多线程服务中某个工作线程出错——正确做法是捕获异常、记录日志、通知监控系统，而不是因为一个线程的问题就杀死整个进程。
• 库（Library/JAR）代码里——你无法控制调用方的上下文，强制退出可能会把宿主应用一起拖下水。
• GUI 程序的事件回调中（比如 Swing 的按钮点击事件）——应该关闭窗口或清空状态，而不是直接调 exit 退出整个应用。