调用 system.exit() 会导致 jvm 进程强制终止，破坏容器生命周期管理；引发请求中断、资源泄漏、数据不一致、线程污染及异步任务丢失；应改用 springapplication.exit()、actuator shutdown 或 sigterm 优雅停机。
在 Web 容器（如 Tomcat、Jetty、Spring Boot 内嵌容器）中调用 System.exit() 会导致整个 JVM 进程被强制终止，而非仅退出当前请求或关闭当前应用——这是严重违反容器生命周期管理的行为，后果远超业务预期。
直接中断容器运行时
Web 容器本身是一个长期运行的 JVM 进程，负责管理 Servlet 生命周期、线程池、连接池、上下文刷新与销毁等。一旦任意业务代码（比如 Filter、Controller、Service）中执行 System.exit(0) 或 System.exit(1)：
- Tomcat/Jetty 的主线程和所有工作线程瞬间终止，HTTP 请求处理被硬性截断，正在响应的客户端收到连接重置（RST）或空响应
- Spring ApplicationContext 不会触发
@PreDestroy、DisposableBean.destroy()或SmartLifecycle.stop() - Actuator 的
/actuator/shutdown端点失效，健康检查探针持续失败，K8s 可能反复重启 Pod
资源泄漏与数据不一致
所有依赖正常关闭流程的资源都无法释放：
- 数据库连接池（HikariCP、Druid）中的活跃连接不会归还或关闭，造成连接泄漏，后续请求可能因获取连接超时而失败
- 事务既不提交也不回滚，数据库可能残留未释放锁或脏数据
- 缓存（Redis 客户端、Caffeine）、消息生产者（KafkaProducer）、文件句柄、NIO Channel 全部丢失清理机会
- 日志框架（Logback、Log4j2）缓冲区未刷盘，最后几条关键错误日志永久丢失
破坏多线程与异步语义
Web 容器高度依赖线程复用和异步调度：
- Servlet 容器线程池中的线程被强制杀死，
ThreadLocal变量无法清理，可能引发内存泄漏或跨请求状态污染 -
CompletableFuture、@Async方法、定时任务（@Scheduled）全部中断，回调永远不会执行 - Filter 或 Interceptor 中调用
System.exit()，会导致同一线程后续被复用时携带异常上下文，影响其他请求
替代方案：交由容器接管退出
Web 应用不该主动终止 JVM，而应让容器按标准流程关闭：
- Spring Boot 推荐使用
SpringApplication.exit(context, exitCode)：它先触发完整关闭钩子，再安全调用System.exit() - 通过 Actuator 的
POST /actuator/shutdown（需启用）发起优雅停机 - 监听
SIGTERM（如 Kubernetes 的 preStop hook），配合server.shutdown.grace-period配置等待时间 - 业务逻辑出错时，抛出受检/非受检异常，由全局异常处理器返回 HTTP 错误码，而非终止进程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
