system.exit()是jvm级强制终止，非普通控制流语句；它立即中断所有线程、跳过finally等清理逻辑，仅执行shutdown hooks，适用场景限于命令行工具完成、启动失败等进程级退出，微服务或web环境中应优先使用框架生命周期管理。
在复杂系统中调用 System.exit() 不是“写完就跑”，而是要权衡上下文、生命周期和协作关系。它不是普通控制流语句，而是一次 JVM 级别的强制终止——一旦触发，整个虚拟机立即进入关闭流程，所有线程中断，未执行的代码（包括 finally 块）将被跳过，只有已注册的关闭钩子（shutdown hooks）会被执行。
明确退出意图：只用于进程级终止
System.exit() 的语义是“这个 Java 进程该结束了”，不是“这个方法/线程/模块该停了”。因此：
- 不要在 Web 请求处理、RPC 方法、定时任务回调、Spring Bean 初始化逻辑中直接调用它来“中断当前操作”——这会杀死整个服务，影响其他请求和健康检查
- 适合场景仅限于：命令行工具执行完毕、单体脚本型应用完成任务、启动阶段失败且无法恢复（如配置严重错误、授权校验失败）、CI/CD 构建脚本中的断言失败
- 若你真正想停止的是某个线程或组件，请改用协作式终止机制（如 volatile 标志位 + 循环检测、
Thread.interrupt()、Spring 的SmartLifecycle.stop()）
状态码要有业务含义，别全用 0 或 1
退出码是系统间通信的重要信号，操作系统、Shell 脚本、Kubernetes 探针都依赖它判断成败：
- 返回
0：表示成功完成预期目标（如导出文件完成、校验通过） - 避免无差别用
1；建议按常见约定分层编码：
2表示命令行参数错误（如main(String[] args)解析失败）
3表示配置加载失败
4表示连接外部服务超时或拒绝
127表示找不到依赖命令（如调用git失败） - Spring Boot 中可结合
SpringApplication.exit(ctx, exitCode)，它会先触发 Spring 生命周期销毁，再调用System.exit()，此时传入的 exitCode 仍会被保留并返回给 OS
清理工作不能靠 System.exit() 自动兜底
虽然 JVM 关闭时会运行 shutdown hooks，但它们有局限性：
- shutdown hooks 是异步执行的，不保证顺序，也不参与 Spring 容器的 Bean 销毁流程（除非你手动注册）
- 不会自动释放你手动
new FileInputStream打开的文件、Socket、数据库连接池外的连接等——这些必须在 exit 前显式 close 或交由容器管理 - 若使用了 JNI 或 native 资源，JVM 不负责回收，必须在 hook 中主动释放
- 推荐做法：把关键清理逻辑封装进 Spring 的
@PreDestroy、DisposableBean或自定义 shutdown hook；System.exit()只作为最终触发点，而非清理入口
多模块/微服务环境下慎用，优先走标准生命周期
在 Spring Boot、Quarkus、Micronaut 等现代框架中，已有成熟退出机制：
- Spring Boot 提供
/actuator/shutdown（需启用）或编程式ConfigurableApplicationContext.close()，能完整走 Bean 销毁、事件发布、资源回收链路 - 嵌入式容器（如 Tomcat、Netty）会在 context 关闭时自动停止监听端口、等待活跃请求完成
- 若你在
@PostConstruct或ApplicationRunner中发现初始化失败，应抛出ApplicationContextException让 Spring 主动中止启动，而不是自己调System.exit()——后者绕过了 Spring 的异常传播与日志记录机制 - 容器化部署（Docker/K8s）中，更应依赖
SIGTERM → graceful shutdown → SIGKILL流程，而非硬退出
