Java中无法真正拦截System.exit()，但可通过自定义SecurityManager在checkExit()中抛出SecurityException来阻断退出，并用try-catch捕获该异常实现软隔离；注意其自Java 17起已弃用，推荐子进程隔离或字节码增强替代。
Java 中无法真正“拦截”第三方库调用 System.exit() 的行为，但可以通过 自定义安全管理器（SecurityManager）配合 try-catch 的有限协同 实现一种近似“软隔离”的保护机制——重点不是捕获异常，而是提前阻断退出动作本身，再配合异常处理做兜底和恢复。
用 SecurityManager 拦截 System.exit() 调用
这是最核心的一步。JVM 允许通过 System.setSecurityManager() 安装一个自定义安全策略，在 checkExit() 方法中抛出 SecurityException，从而阻止进程退出。
- 需在调用第三方库前安装（且仅能安装一次，后续不可替换）
- 必须继承
SecurityManager并重写checkExit(int status) - 抛出的
SecurityException可被外层 try-catch 捕获，实现控制流回归
System.setSecurityManager(new SecurityManager() {
@Override
public void checkExit(int status) {
throw new SecurityException("Exit blocked: third-party library attempted System.exit(" + status + ")");
}
});
在受控上下文中执行第三方代码
将第三方调用包裹在 try-catch 中，并确保 SecurityManager 已就位。注意：catch 必须捕获 SecurityException（以及可能的其他运行时异常），且不能遗漏 Throwable（因某些库可能绕过 SecurityManager 抛出未检查错误）。
- 推荐 catch
SecurityException和RuntimeException，必要时加catch (Throwable t) - 避免在 catch 块中再次调用可疑库或执行复杂逻辑，防止二次崩溃
- 可记录日志、重置状态、返回默认值或触发降级流程
注意 JVM 层级限制与替代方案
SecurityManager 自 Java 17 起已被弃用，且在 Java 21+ 默认禁用；现代 JDK（如 21+）需显式启用（--enable-preview --illegal-access=permit 等），生产环境不推荐依赖。
立即学习“Java免费学习笔记（深入）”；
- 更可靠的替代是进程级隔离：用独立子进程（
ProcessBuilder）运行第三方库，主进程监听其退出码并决定是否重启或告警 - 若必须同进程运行，可结合字节码增强（如 Byte Buddy）在类加载时重写目标类的
System.exit()调用，但侵入性强、调试难 - 优先推动第三方库修复问题——向其提交 issue，说明
System.exit()违反 JVM 库设计契约
实际封装建议
把隔离逻辑封装为可复用的工具方法，降低误用风险：
- 提供
executeSafely(Runnable task)方法，内部自动设置/恢复 SecurityManager（注意线程安全） - 对返回值场景，使用
<T> T executeSafely(Supplier<T> supplier) - 超时控制可叠加
CompletableFuture.orTimeout()，防止单次调用无限阻塞
