Java应用通过操作系统SIGTERM信号触发JVM标准退出流程，由Shutdown Hook执行清理，而非直接使用System.exit；现代JDK内置信号响应机制，无需手动注册SignalHandler；部署时应依赖标准信号机制并正确实现Shutdown Hook。
Java 应用在部署中不直接靠 System.exit 响应信号量退出，而是通过操作系统信号（如 SIGTERM）触发 JVM 的标准退出流程，再由 Shutdown Hook 完成清理——System.exit 本身不“监听”信号，它只是退出动作的其中一种触发源。
信号量如何触发退出流程
Linux/Unix 系统中，运维常用 kill -15 <pid>（即发送 SIGTERM）通知 Java 进程优雅关闭。JVM 内部会将该信号转化为等效的 System.exit(143)（注意：143 是 SIGTERM 的常见退出码，但非强制），进而启动 Shutdown Hook 执行序列。
-
不是 Java 代码主动捕获信号再调用 exit：现代 JDK（8+）已内置对
SIGTERM的响应，无需手动注册SignalHandler（该 API 已被标记为 deprecated，且行为不稳定） -
真正起作用的是 JVM 层机制：收到
SIGTERM后，JVM 自动开始 shutdown 序列，与调用System.exit(0)触发的流程完全一致 -
避免手动用 SignalHandler + System.exit 组合：旧式写法（如用
sun.misc.Signal）兼容性差、易出错，且可能干扰 JVM 原生信号处理
部署时推荐的退出方式
容器化或 systemd 管理的场景下，应依赖标准信号机制，而非在业务代码里硬编码 System.exit：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
Kubernetes / Docker：发送
SIGTERM（默认），等待 grace period 后再发SIGKILL；应用只需注册 Shutdown Hook，无需干预信号接收 -
systemd 服务：配置
KillSignal=SIGTERM和TimeoutStopSec=30，确保有足够时间执行钩子 -
Spring Boot：启用
spring.lifecycle.timeout-per-shutdown-phase=30s，配合 Actuator 的/actuator/shutdown（本质也是触发System.exit或上下文关闭）
Shutdown Hook 是核心枢纽
所有退出路径（System.exit、Ctrl+C、kill -15、系统关机）最终都汇入同一套钩子执行逻辑：
立即学习“Java免费学习笔记（深入）”；
- 用
Runtime.getRuntime().addShutdownHook(new Thread(...))注册清理任务 - 钩子里应做：关闭线程池、刷新日志、提交未完成事务、通知注册中心下线、释放本地锁文件等
- 钩子必须轻量、无阻塞、不依赖外部服务（因网络/DB 可能已不可用）
- 多个钩子间无顺序保证，彼此独立设计
绝对要避开的坑
部署稳定性高度依赖退出路径的可控性，以下操作会破坏优雅停机：
-
在业务线程中调用
System.exit：可能导致部分请求正在处理时被强杀，订单/支付状态不一致 -
用
kill -9强制终止：绕过所有钩子和清理逻辑，必然导致资源泄漏、数据丢失、文件损坏 -
钩子里再调用
System.exit或启动新线程：可能引发死锁或未定义行为 -
依赖 finally 或 try-with-resources 替代钩子：它们在
System.exit或SIGTERM下根本不会执行
