能通过SecurityManager的checkExit()在System.exit()执行前阻断退出流程，核心是抛出SecurityException中断控制流；需在启动时设置，Java 17+已弃用，应改用子进程隔离等替代方案。
不能真正“拦截”System.exit()，但能用 SecurityManager 在它执行前主动阻断——关键不是捕获退出，而是不让它走完退出流程。
核心机制：checkExit() 是唯一入口
System.exit() 内部会调用 Runtime.exit()，而后者第一件事就是查安全管理器：
如果设置了 SecurityManager，就会调用它的 checkExit(int status) 方法；
只要在这个方法里抛出 SecurityException（或任意运行时异常），JVM 就不会继续执行后续的关机逻辑。
- 这个检查发生在退出动作真正开始前，属于策略性拒绝，不是事后补救
- 必须在任何第三方代码运行前安装，且 JVM 全局只能设一次
- 不依赖 try-catch 捕获退出本身，而是靠异常中断控制流，让程序回到上层逻辑
具体实现：自定义 SecurityManager
继承 SecurityManager，重写 checkExit()，直接抛异常：
public class NoExitSecurityManager extends SecurityManager {
@Override
public void checkExit(int status) {
throw new SecurityException("System.exit(" + status + ") is blocked");
}
}
- 不需要重写其他方法（如
checkPermission），除非你还要限制文件、网络等操作 - 启动时设置：
System.setSecurityManager(new NoExitSecurityManager()); - 注意：Java 17 起已弃用
SecurityManager，该方式仅适用于 Java 8–16 环境
配合 try-catch 做流程恢复
抛出的 SecurityException 可被外层 try-catch 捕获，用于记录日志、清理资源或切换执行路径：
System.setSecurityManager(new NoExitSecurityManager());
try {
thirdPartyLib.doSomething(); // 可能内部调用 System.exit(1)
} catch (SecurityException e) {
System.err.println("Exit blocked: " + e.getMessage());
// 继续执行降级逻辑，比如返回错误码、重试或标记失败
}
- 异常消息里可带状态码，方便区分是正常退出还是错误终止
- 别指望 finally 块在
System.exit()后还能执行——只有被SecurityManager阻断后，finally 才有效 - 若需更细粒度控制（比如只拦第三方、不禁自己），可在
checkExit()中判断调用栈，但要注意性能开销
替代方案提醒（Java 17+ 必须考虑）
因为 SecurityManager 已被移除，生产环境应转向更现代的隔离手段：
- 子进程隔离：把第三方库放在独立 JVM 进程中运行，主进程通过 IPC 通信，退出只影响子进程
-
字节码增强：用 ByteBuddy 或 ASM 在类加载时重写
System.exit()调用，替换成日志记录或回调 -
容器级防护：在 Docker/K8s 中限制进程权限，配合
seccomp或capabilities拦截exit_group系统调用
