system.exit()的状态码遵循posix约定：0表示成功，非零表示失败；应严格限定在0–127范围内，避免截断错误；在spring、web容器和测试中禁用，改用优雅退出机制。
System.exit() 的状态码不是 Java 自己定的，而是沿用操作系统（尤其是 POSIX 兼容系统）的通用约定：0 表示成功，非零表示失败。这个数字会真实传递给父进程或 shell，被脚本、CI/CD 流水线、容器编排（如 Kubernetes）用来判断程序是否“按预期结束”。用错状态码，下游就可能误判运行结果。
0 和非零：最核心的语义分界
状态码 0 是唯一被广泛识别为“成功”的值。几乎所有 shell 脚本都用 if [ $? -eq 0 ] 判断上一条命令是否成功；CI 工具默认把非零退出当作构建失败；Kubernetes 的 liveness/readiness probe 也依赖它做健康决策。一旦返回非零（哪怕只是 1），就等同于向外界宣告：“这次执行没完成预期目标”。
- 0 不代表“没出错”，而代表“完成了该做的事”——比如命令行工具正确输出帮助信息后退出，就该用 0
- 非零不等于“崩溃”，而是“未达成目标”——参数校验失败、文件找不到、网络超时，都该用不同非零值区分
- 不要用 0 掩盖问题：比如 catch 到异常却仍调 System.exit(0)，会让监控和运维完全无法察觉故障
状态码取值范围与平台截断规则
Java 本身不限制 status 参数大小，但操作系统只保留低 8 位（0–255）。超出范围的值会被自动截断，容易引发隐性错误：
- 负数如
System.exit(-1)→ shell 中$?显示为 255（因为 -1 & 0xFF = 255） - 大于 255 的数如
System.exit(256)→ 截断为 0，看似成功，实则掩盖严重错误 - 建议严格限定在 0–127：0 表示成功；1–127 用于自定义错误（如 1=通用错误，2=IO 错误，10=配置缺失）
Web/Spring/测试环境中的禁用场景
在托管环境中硬杀 JVM，会跳过关键清理逻辑，造成资源泄漏或状态不一致：
- Spring Boot 应用里调
System.exit()，会绕过@PreDestroy、事务回滚、连接池关闭，甚至导致注册中心残留无效实例 - JUnit 测试中使用，会使整个测试套件中断，后续用例不再执行；应改用
Assert.fail()或抛出测试专用异常 - Servlet 容器（Tomcat/Jetty）中禁止调用，否则可能卡住线程池、丢弃未 flush 的日志、遗漏 shutdown hook
更安全的替代方案
多数时候你不需要“杀死 JVM”，只需要“退出当前执行流并告知结果”：
- 命令行工具主函数：用
return让 main 自然结束，JVM 默认以 0 退出；出错时抛出自定义异常，在顶层捕获后打印提示并返回对应非零码 - Spring Boot 应用：用
SpringApplication.exit(context, exitCode)触发优雅关闭流程，支持自定义退出码和回调 - 微服务下线：先调用 Nacos/Eureka 注销接口，再关闭 WebServer，最后让 JVM 在 SIGTERM 信号下自然终止，而非主动
System.exit()
