system.exit状态码是给操作系统和外部调用方看的语义标签，不终止进程也不触发清理；真正决定安全退出的是shutdown hook、框架关闭流程与容器信号协同，状态码仅说明退出原因，必须严格限定在0–127范围内，0表示已妥善收尾，1–125供业务自定义错误，126–127为shell预留，应避免负数、143等冲突值，并与运维脚本、k8s探针对齐。
System.exit 状态码不是 JVM 的“退出指令”，而是给操作系统和外部调用方看的语义标签。它本身不终止进程，也不触发清理——真正决定是否安全退出的，是 shutdown hook 是否注册、框架关闭流程是否走完、容器信号是否协同。状态码只负责说清楚“为什么退出”。
状态码的取值边界与语义约定
必须严格控制在 0–127 范围内，超出部分会引发歧义或被系统重映射：
- 0：唯一表示“逻辑完成、资源就绪、可回收”的成功码；不是“没出错”，而是“已妥善收尾”
- 1–125：留给业务自定义错误，例如 101=数据库连接失败、102=配置校验不通过、110=主动降级退出
- 126–127：Shell 预留，脚本中用于命令权限或路径问题，Java 程序应避开
- 128+N：仅当配合信号监听库（如 JNA 或 Spring Boot signal handler）时才有意义，如 130 = 128 + SIGINT
- 避免负数（如 System.exit(-1) 实际返回 255）、避免 143（与 kill -15 冲突）
状态码要嵌入业务逻辑分层设计
不能靠临时判断填数字，而应作为错误分类体系的一部分：
- 定义常量类统一管理，例如：public static final int DB_INIT_FAILED = 101;
- 按错误阶段归类：启动期（1xx）、运行期（2xx）、外部依赖（3xx）、用户输入（4xx）
- 每个非零码需写入项目文档，并与运维脚本、告警规则对齐，否则对 CI/CD 和 K8s readinessProbe 无实际价值
- Web 应用中，状态码不应由业务 Controller 直接设置，而应由 Actuator /shutdown 端点或 SpringApplication.exit() 统一返回
状态码与真实退出动作必须解耦
设了 System.exit(0) 不代表进程干净退出——关键看退出前是否完成以下动作：
- 注册 ShutdownHook 并确保其执行：关闭线程池、flush 日志缓冲区、调用服务下线 API、写入心跳结束标记
- 钩子内禁止网络调用、阻塞 I/O、再调用 System.exit()，超时建议控制在 3–5 秒内
- Docker/K8s 环境中，需匹配 STOPSIGNAL SIGTERM，并在收到 SIGTERM 后等待优雅期再调用 exit(0)，而非立即退出
- 多线程场景下，确保所有非守护线程已终止，否则容器可能卡在 Running 状态，状态码失去意义
不该用 System.exit 的典型误用场景
这些情况即使设了规范状态码，也属于“伪安全”：
- Spring Boot 业务代码里调用 System.exit()：干扰健康检查、绕过 Bean 销毁、破坏连接池回收
- 被第三方库（如旧版 Log4j 或 Dubbo）内部触发：导致整个应用静默退出，难以定位
- 非主线程中调用：杀的是整个 JVM，不是当前线程，极易引发并发资源残留
- 未注册任何 ShutdownHook 就设 exit code：状态码成了空口号，OS 看到的是“进程崩溃式退出”
