system.exit() 是 jvm 内部的主动终止机制，不涉及信号量处理，也不触发操作系统信号；它直接终止 jvm，仅执行 shutdown hooks，不可被 try-catch 捕获，也无法用信号量拦截。
System.exit() 本身不涉及信号量处理，也不是操作系统信号（如 SIGTERM），它属于 JVM 内部的主动终止机制，直接触发虚拟机退出流程，绕过常规异常传播链和资源清理逻辑。因此，“System.exit 的信号量处理”这一说法存在概念混淆——信号量（semaphore）是用于线程/进程同步的计数器机制，而 System.exit() 是 Java 层的控制流指令，二者无直接关联。
System.exit() 的真实行为本质
调用 System.exit(int status) 会立即向 JVM 发送“强制终止”指令，JVM 随即：
- 停止所有非守护线程（包括正在执行的 finally 块、shutdown hooks 仍可运行）；
- 不抛出可捕获的异常（它不是 Throwable 子类，也不走 try-catch 路径）；
- 跳过普通异常处理机制，但会执行已注册的 shutdown hook；
- 最终调用本地方法
Runtime.getRuntime().exit(status)，由 JVM 底层调用exit()系统调用结束进程。
为什么不能用信号量拦截 System.exit()
信号量用于协调多个线程对共享资源的访问，而 System.exit() 是单点、全局、不可逆的 JVM 终止动作。它不依赖、也不触发任何信号量操作：
- POSIX 信号（如 SIGKILL、SIGTERM）由操作系统发送，可被 signal handler 捕获；System.exit() 不发信号，它是 Java API 的同步调用；
- 即使你在代码中用信号量保护某段逻辑，也无法阻止其他地方调用 System.exit() —— 它完全绕过用户代码的同步控制；
- 试图用信号量“等待 exit 完成”或“阻止 exit 执行”没有意义，因为 exit 后整个进程空间消失，信号量对象也随之销毁。
真正可行的拦截与监控手段
若需定位或限制 System.exit() 调用，应采用 JVM 层级的管控方式：
-
SecurityManager（JDK 17 前）：重写
checkExit(int)方法并抛出自定义异常，可记录调用栈（但该机制已被 JDK 17 废弃）； -
字节码插桩（推荐）：使用 ByteBuddy 或 ASM 在类加载时增强
System.exit()方法，插入日志、堆栈打印或抛出受控异常； -
JVM 启动参数辅助：添加
-Xrs减少 JVM 对某些信号的响应干扰，便于区分是信号退出还是 exit() 退出； - 日志与监控联动：在应用启动时注册 shutdown hook，记录 exit 前状态；结合 APM 工具（如 SkyWalking）捕获进程退出事件及时间戳。
对比 Python 的 sys.exit()
Python 中 sys.exit() 会引发 SystemExit 异常，因此可在 try-except 中捕获并干预：
try:
sys.exit(1)
except SystemExit as e:
print(f"拦截退出，状态码：{e.code}")
# 执行清理
finally:
cleanup_resources()
这是语言设计差异：Python 将退出建模为异常，Java 则将其设计为底层终止指令。不要将 Python 的捕获逻辑套用到 Java 的 System.exit() 上。
