Java应用应通过Shutdown Hook响应SIGTERM、SIGINT、SIGHUP等信号，由JVM内置机制自动触发退出流程；禁用手动SignalHandler，因JDK 9+已弃用且易引发竞态；SIGKILL等强制信号无法拦截。
Linux 中的信号机制本身不通过 Java 代码“捕获”，JVM 层已内置响应逻辑；Java 程序应聚焦于注册 Shutdown Hook 来响应可拦截信号（如 SIGTERM、SIGINT），而非手动监听或处理信号。
哪些信号能触发 JVM 正常退出流程
以下信号会启动 JVM 标准关闭序列，从而运行 Shutdown Hook：
-
SIGTERM（
kill -15 <pid>）：容器编排（如 Kubernetes）、服务管理器（systemd）最常用的优雅终止信号 -
SIGINT（
Ctrl+C）：终端交互式中断，开发调试常见 - SIGHUP（挂起终端时）：部分守护进程场景下可能触发（取决于启动方式）
这些信号由操作系统发送给 JVM 进程，JVM 内部自动将其转化为等效的 System.exit(143)（SIGTERM）、System.exit(130)（SIGINT）等调用，进而启动 Shutdown Hook 执行链。
为什么不要手动注册 SignalHandler
旧式写法（如使用 sun.misc.Signal 或 Signal.handle()）存在明显缺陷：
立即学习“Java免费学习笔记（深入）”；
- 该 API 自 JDK 9 起被标记为
@Deprecated，JDK 17+ 已移除支持 - 行为不稳定，可能干扰 JVM 原生信号处理逻辑，导致钩子不执行或进程卡死
- 无法覆盖 JVM 对 SIGTERM 的默认响应，反而可能引发竞态或重复退出
现代 JDK（8u231+ 及所有 JDK 11/17/21 LTS 版本）已完整接管 SIGTERM/SIGINT 处理，无需、也不应干预。
正确做法：用 Shutdown Hook 响应信号
只需在应用启动早期注册一个或多个 Thread 类型的钩子，JVM 在收到上述任一可拦截信号后，会自动调用它们：
- 钩子线程中可执行连接池关闭、活跃请求等待、事务提交、日志刷盘等清理动作
- 避免耗时操作（如网络调用、无界循环），因 OS 通常只预留几秒至几十秒宽限期（如 systemd 默认 10s）
- 多个钩子并发执行，无固定顺序，需自行加锁或协调资源释放顺序
- 钩子内不可再调用
System.exit()，否则可能死锁或跳过后续钩子
哪些情况完全无法响应
以下情形会绕过 JVM 关闭流程，Shutdown Hook 不会执行：
-
kill -9 <pid>（SIGKILL）：OS 强制终止，进程立即销毁 -
taskkill /f /pid <pid>（Windows）：同 SIGKILL 效果 - JVM 崩溃（如 JNI 段错误、内存越界）、主机断电、OOM 导致进程被内核 kill
这类强制退出属于系统级操作，任何 Java 层机制都无法拦截——这是 JVM 规范明确限定的边界。
