System.exit状态码仅向OS返回整数退出码，不负责终止进程；真正安全注销依赖ShutdownHook清理、框架关闭流程及容器信号协同，状态码仅表意。
System.exit 状态码本身不能“通知操作系统注销进程”，它只是向操作系统返回一个整数退出码。真正决定进程是否安全终止的，是 JVM 关闭流程中是否完成资源清理、服务下线、状态持久化等动作——状态码仅是这个过程的最终语义标记，不是执行者。
状态码的语义规范：让外部系统读懂你的意图
退出码是给 Shell 脚本、容器编排系统（如 Kubernetes）、监控告警等调用方看的，不是 JVM 自己用的：
- 0：表示逻辑执行完毕、资源已释放、可安全回收
-
1–125：推荐用于业务级错误，例如
System.exit(101)表示数据库连接失败，System.exit(102)表示配置加载异常 - 126–127：Shell 预留码，脚本中常用于命令权限或路径问题，Java 程序应避开
-
128+N：对应信号中断，如
130 = 128 + 2表示收到 SIGINT（Ctrl+C），需配合信号监听库（如 JNA 或 Spring Boot 的 signal handling）才有意义
真正安全退出的核心：ShutdownHook 必须到位
没有 ShutdownHook，再规范的状态码也等于“假安全”。JVM 在调用 System.exit() 后会自动触发已注册的钩子，这是唯一可控的清理窗口：
- 用
Runtime.getRuntime().addShutdownHook(new Thread(() -> { /* 清理逻辑 */ }))注册钩子 - 钩子里只做轻量、无依赖操作：关闭线程池、刷新日志缓冲区、写入心跳结束标记、调用服务下线 API
- 避免网络调用、阻塞 I/O 或长耗时操作；超时建议控制在 3–5 秒内
- 多个钩子并发执行，不保证顺序，共享资源需自行加锁或使用原子操作
容器与操作系统协同：信号、优雅期、状态码要对齐
在 Docker/K8s 环境中，单纯 System.exit(0) 不代表容器能干净退出：
- Dockerfile 中显式声明
STOPSIGNAL SIGTERM，确保 kill -15 能触发 ShutdownHook - 收到 SIGTERM 后，应等待优雅期（如 30 秒），再调用
System.exit(0)；不要立即退出 - K8s 中 readinessProbe 失败后主动下线，此时可用
System.exit(110)标识“主动降级退出”，便于运维识别 - 确保所有非守护线程已终止——否则即使状态码为 0，容器仍可能卡在 Running 状态
常见误区：这些做法看似“设了码”，实则不安全
以下行为无法达成物理层面的安全注销：
- 仅调用
System.exit(0)却未注册任何 ShutdownHook - 在钩子里再次调用
System.exit()，导致 JVM 二次关闭，行为未定义 - 依赖
finally块做清理——System.exit()后finally不执行 - 在 Web 容器（如 Tomcat）或安全管理器启用环境下直接调用，可能抛出
SecurityException
