System.exit在应用服务器中被禁止，因其会强制终止JVM，破坏容器生命周期管理；实际常被SecurityManager拦截或静默忽略，正确做法是抛异常触发优雅关闭而非强行退出。
System.exit 在应用服务器（如 Tomcat、WebLogic、Spring Boot 内嵌容器）中被限制，不是因为“权限不足”，而是被主动拦截或失效——本质是运行环境通过安全管理器（SecurityManager）或容器自身机制阻止了 JVM 强制退出行为。它不是操作系统层面的权限问题，而是 Java 运行时策略与容器生命周期管理的硬性约束。
为什么 System.exit 在应用服务器里常“不生效”或被禁止
应用服务器启动后，会接管整个 JVM 生命周期。此时调用 System.exit() 通常会：
- 触发 SecurityManager.checkExit() 检查，若策略禁止则直接抛出 SecurityException，进程继续运行
- 在 Spring Boot 等现代框架中，即使没配安全管理器，exit 调用也可能被静默忽略（尤其在非 main 线程中）
- Tomcat 的 shutdown hook 机制虽响应 exit，但若容器已进入 RUNNING 状态，exit 反而可能引发未定义行为或被线程上下文压制
- 像 Dubbo 注册中心初始化失败时调用 System.exit(1)，若发生在后台线程或回调中，主线程仍存活，JVM 不会真正退出（见知识库中 2023 年案例）
如何确认是否被安全管理器拦截
可在代码中显式检查并捕获异常：
try {
System.exit(1);
} catch (SecurityException e) {
// 被安全管理器拒绝，可记录日志或转为抛出 RuntimeException
log.warn("System.exit blocked by SecurityManager", e);
throw new RuntimeException("Critical init failure, but exit disabled", e);
}
也可通过 JVM 参数验证是否存在安全管理器：
- 启动时加 -Djava.security.manager 表示启用默认策略
- 代码中调用 System.getSecurityManager() 返回非 null 即表示已激活
替代方案：安全、可控的终止方式
不要绕过限制强行 exit，而应适配容器模型：
- 对 Spring Boot 应用：抛出 RuntimeException（如 ApplicationContextException），由 SpringApplication 捕获后执行优雅关闭流程
- 对 Tomcat 部署的 WAR：在 ServletContextListener.contextInitialized 中检测失败，记录错误后让容器自然启动失败（不调用任何 exit）
- 需要通知外部系统：通过 HTTP 健康检查端点返回 503，或调用注册中心下线 API，交由运维/编排平台（如 Kubernetes）决定是否重启
- 命令行工具或独立模块：确保它不被 Web 容器加载；若必须共存，用 ClassLoader 隔离或启动独立 JVM 进程
运维侧兜底：避免故障扩散
生产环境应主动防御误用：
- 构建阶段用 SonarQube 或 Checkstyle 规则扫描 System\.exit\(，禁止提交
- JVM 启动参数加入 -Djava.security.manager -Djava.security.policy==/path/to/restrictive.policy，明确禁止 exit 权限
- 在 CI/CD 流水线中注入字节码扫描（如 Byte Buddy 或 ASM），对已编译 class 文件做 exit 调用拦截告警
- 监控 JVM 进程意外退出事件（如通过 systemd 日志、APM 工具捕获 SIGTERM/SIGKILL），反向定位非法 exit 调用点
