Java无法真正拦截System.exit()，但可通过SecurityManager（JDK17+需显式启用）、ShutdownHook、字节码增强或Mockito等手段，在退出前依条件断言链决定放行、降级或抛出异常，实现可控退出。
Java 中无法真正“拦截”System.exit() 的调用，因为它是 JVM 级别的强制终止操作；但可以通过 安全管理器（SecurityManager） 或 JVM 启动参数 + 自定义退出钩子 的组合方式，在运行时检测、记录甚至阻止其执行——关键在于“条件断言链”的设计逻辑：不是拦截已发生的 exit，而是在 exit 触发前，依据多层条件动态决定是否放行、降级或抛出异常。
用 SecurityManager 实现条件化拒绝
这是最接近“拦截”的标准机制（注意：JDK 17+ 默认禁用，需显式启用）：
- 自定义
SecurityManager子类，重写checkExit(int status) - 在方法内构建断言链：例如检查当前线程名是否为 "test-thread"、调用栈是否含 "JUnit"、状态码是否为 0、是否处于单元测试环境等
- 若任一条件不满足（如非测试环境却调用了 exit），则抛出
SecurityException，中断退出流程 - 启动时加参数：
-Djava.security.manager=allow -Djava.security.policy==./security.policy，并在 policy 文件中授予权限（否则直接被拒绝）
用 Runtime.addShutdownHook + 条件标记实现“软拦截”
ShutdownHook 在 exit 调用后、JVM 终止前执行，不能阻止退出，但可用于审计与补偿：
- 提前注册一个 hook，内部检查全局标志位（如
AtomicBoolean shouldBlockExit） - 配合条件断言链：例如判断当前是集成测试阶段、且 exit status == 1、且无活跃 HTTP 请求，则记录警告并 dump 线程栈
- 若需“模拟拦截”，可在 hook 中调用
Thread.sleep(Long.MAX_VALUE)（不推荐生产），或触发System.gc()+ 日志告警，为运维争取响应时间
用字节码增强（如 ByteBuddy）在调用点注入断言
适用于无法修改源码、又需强管控的场景：
- 在类加载时拦截所有对
System.exit()的调用，动态插入条件判断字节码 - 断言链可读取 MDC 上下文、Spring Profile、JVM 参数（如
spring.profiles.active）、甚至远程配置中心开关 - 例如：仅当
env=prod且exit.status != 0时，才真正执行 exit；否则转为抛出RuntimeException("Exit blocked by policy") - 需配合 agent 方式启动：
-javaagent:exit-guard-agent.jar
测试阶段专用：Mockito + PowerMock 替换 System 类
单元测试中彻底避免 JVM 退出，保障测试稳定性：
- 用 PowerMock 的
@PrepareForTest({System.class})允许 mock 静态方法 - 在测试 setup 中 mock
System.exit()，使其不真正退出，而是设置一个 int 字段记录期望退出码 - 断言链体现在测试逻辑中：例如 “当用户输入非法参数时，应调用 exit(1)，且日志包含 ERROR”
- 注意：PowerMock 不兼容 JDK 9+ 模块系统，新项目建议改用 Testcontainers 或进程级集成测试替代
本质上，“拦截 System.exit” 是一种防御性编程策略，核心不在技术对抗，而在分层设防：开发期用 mock、测试期用 security manager、预发用字节码增强、生产期靠监控告警+快速回滚。条件断言链的价值，是让每次 exit 都可追溯、可配置、可审计。
