System.exit()退出码是面向操作系统和外部调用方的语义协议，必须严格遵循0（成功）、1–125（自定义业务错误）、避开126–127及128+（系统保留），禁用负数，统一用常量封装，并配合日志与Shell/CI正确捕获处理。
System.exit() 的退出码不是随便填的数字，它是一套面向操作系统和外部调用方（如 Shell 脚本、CI 流程、K8s 健康检查）的语义协议。用错值不仅会让下游误判，还可能掩盖真实问题。
退出码取值范围与安全边界
状态码会被操作系统截断为 0–255 的无符号字节，超出部分会取模：
- 0：唯一被广泛认可的“成功”信号，必须仅用于全部逻辑完成且资源清理就绪的情况
-
1–125：推荐自定义业务错误码，例如
INVALID_ARGS = 1、CONFIG_ERROR = 2、DB_FAILURE = 3 - 126–127：Shell 预留（如命令不可执行、命令未找到），Java 程序应主动避开
-
128+：系统保留，通常表示被信号终止（如
130 = 128 + SIGINT），除非你显式监听信号并有意映射，否则不要直接返回 -
负数：JVM 会转为
value & 0xFF，例如System.exit(-1)实际返回255，易引发歧义，应杜绝
代码中定义与使用退出码
避免魔法数字，用常量类封装语义，提升可读性和可维护性：
- 定义统一出口码类，如
ExitCode，所有模块复用同一套含义 - 在关键分支中明确调用，例如参数校验失败时
System.exit(ExitCode.INVALID_ARGS) - 主方法自然结束时，JVM 默认返回 0；若需显式控制，仍建议写
System.exit(ExitCode.SUCCESS)保持一致性 - 不把退出码当作日志替代——错误原因仍需打印到 stdout/stderr，状态码只作结构化判断依据
Shell 脚本中捕获与响应
退出码只有被正确读取和分支处理，才能发挥价值：
- 执行后立即获取
$?，不要中间插入其他命令（哪怕只是echo） - 用
case或if明确区分不同码值，例如：if java -jar app.jar; then deploy.sh; else echo "启动失败，退出码: $?" >&2; exit 1; fi - CI/CD 中可配置多级响应：码为 0 → 标记成功；码为 1–5 → 重试；码 ≥ 100 → 中止流水线并告警
- 避免只做
if [ $? -eq 0 ]这类二元判断，丢失错误分类能力
常见故障与排查路径
进程“悄无声息”退出或“该退不退”，往往不是退出码本身的问题，而是上下文异常：
-
日志中断但无堆栈：检查是否第三方库（如 Log4j、Kafka Client）在异常路径中调用了
System.exit()，启用字节码插桩或添加 SecurityManager 拦截 - 调用 System.exit() 后进程仍在：常见于 Dubbo、Spring Boot 等框架主线程被阻塞（如注册中心连接等待），导致 JVM 无法真正终止；改用异步线程触发或走框架关闭流程
-
返回码始终是 0：检查是否传入了 256 或更大值（
256 % 256 == 0），或负数被截断 -
容器未及时回收：确认非守护线程已全部结束，ShutdownHook 执行完毕，且 Dockerfile 设置了
STOPSIGNAL SIGTERM
