优雅退出JVM的核心答案：提前注册Shutdown Hook，并在其中有序关闭线程池、连接池和文件流，同时让应用以响应SIGTERM信号的方式接收运维停止指令，这样资源就不会泄漏。 优雅退出不是靠运气,而是靠一套可重复执行的清理机制。
JVM退出方式对比：kill -9、System.exit与SIGTERM谁更安全？
想象一个深夜生产场景：支付服务正在处理批量订单，运维因为内存告警直接敲下kill -9，几秒后进程消失，但数据库连接池里的空闲连接还挂在远端，消息队列的消费者也没摘下队列，端口被旧进程的线程占着，新实例起不来，这种事故,几乎都源于用了最粗暴的退出方式。
JVM有几种不同的退场路径,安全等级天差地别：
- kill -9（SIGKILL）：操作系统直接回收进程，JVM没有任何机会执行清理代码，Shutdown Hook全部失效,资源泄漏概率最高。
- System.exit(0)：触发JVM关闭流程，会执行Shutdown Hook，但不会展开当前线程的栈，所以
finally块不保证执行。 - kill -15（SIGTERM）：默认终止信号，JVM会捕获并启动Shutdown Hook,这是最常用的优雅退出入口。
| 退出方式 | 信号/调用 | 执行Shutdown Hook | 资源清理能力 | 生产环境推荐度 |
|---|---|---|---|---|
| kill -9 | SIGKILL | 否 | 无 | 极低 |
| System.exit(0) | 方法调用 | 是 | 部分 | 中 |
| kill -15 | SIGTERM | 是 | 完整 | 高 |
业内专家指出，强制终止造成的故障往往在流量高峰才暴露，而优雅退出虽然多花几秒等待，却能避免一连串的雪崩，运维脚本里应该优先使用kill -15，而不是kill -9。
用Shutdown Hook优雅关闭资源：三步实操指南
Shutdown Hook是JVM留给应用的最后一次清理机会，注册一个钩子，让JVM在退出前执行指定代码,这是手动优雅退出最基本的手段。
常见的注册方式：
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
// 清理逻辑
}));但要真正做到优雅,需要遵循三个步骤：
- 停止接收新任务：先关闭入口，比如取消消息监听、摘掉负载均衡上的节点,确保没有新流量进来。
- 处理已提交任务：调用线程池的
shutdown()，然后awaitTermination(30, TimeUnit.SECONDS),给正在跑的任务留出收尾时间。 - 关闭外部资源：数据库连接池调用
close()，文件流关闭，HTTP客户端关闭，顺序上先业务资源,后基础资源。
一个常见的失败模式是只调用了shutdownNow()，导致线程被暴力中断，DB事务回滚不完整，正确做法是分两步：先shutdown等待，超时后再shutdownNow兜底。
JVM退出时线程池没关闭？三步定位并优雅回收
如果你发现重启后端口仍被占用，输入jstack <pid>，能看到类似pool-1-thread-1的工作线程还挂着,这说明线程池没有被回收。
第一步，确认线程池是否设置了allowCoreThreadTimeOut(true)，如果没有，核心线程默认常驻，即使空闲也不会退出，第二步，检查Shutdown Hook里有没有调用executor.shutdown()，第三步，如果Hook里只调用了shutdown，但内存中的队列还有积压任务，awaitTermination超时后仍不结束，就需要在超时后调用shutdownNow()，并丢弃或持久化剩余任务，据统计，线程池泄漏是JVM退出场景中最常见的问题，多数情况下是因为只关注了连接池,忽略了线程池。
Spring Boot优雅停机配置详解：零成本实现资源安全释放
从Spring Boot 2.3开始，内置了优雅停机能力，不需要额外引入组件，完全零成本，只需在application.yml中配置两个参数：
server:
shutdown: graceful
spring:
lifecycle:
timeout-per-shutdown-phase: 30s
这段配置生效后，收到SIGTERM时，Web容器会先停止接收新请求，等待已进入的请求处理完，再关闭Spring容器，最后触发JVM的Shutdown Hook。
但注意：Spring Boot的优雅停机只覆盖Web请求生命周期，对于你自己创建的线程池、定时任务、消息消费者，Spring并不知道如何关闭，行业共识认为，Spring Boot的优雅停机是安全基线，但自定义资源仍需手动兜底，常见做法是在@PreDestroy注解方法里关闭这些资源：
@PreDestroy
public void shutdown() {
executor.shutdown();
connectionPool.close();
}
生产环境JVM退出怎么避免数据丢失？先看Spring生命周期顺序
很多开发者在@PreDestroy里注销服务注册，但发现流量还是切过来，原因是Spring容器关闭时，SmartLifecycle的stop()会先执行，然后再执行@PreDestroy，最后才是JVM Shutdown Hook，如果你想在下线时先把当前节点从注册中心摘掉，应该实现SmartLifecycle的stop()方法，或者在@PreDestroy中先调用discoveryClient.unregister()，否则，在注销生效前,新流量已经打到了正在关闭的节点上。
Kubernetes下JVM优雅下线：避免Pod被杀引发雪崩
Kubernetes滚动更新时，Pod进入Terminating状态，向主容器发送SIGTERM，默认的terminationGracePeriodSeconds是30秒，如果JVM在30秒内没有退出，kubelet会强制发送SIGKILL，这个场景里，即使你写了Shutdown Hook,也可能没机会跑完。
解决方案分三层：
- 应用层：注册Shutdown Hook，并尽量在10秒内完成清理,预留时间余量。
- 配置层：把
terminationGracePeriodSeconds调大到60秒或更高，特别是Spring Boot应用需要等待请求处理完。 - 集群层：在Pod的
preStop钩子里添加一笔短暂等待，例如sleep 5,让服务注册中心有足够时间摘除旧节点。
针对Spring Cloud微服务，国内不少团队的Kubernetes集群都踩过同一个坑：应用没有在关闭时注销Nacos或Eureka，导致客户端还往旧Pod地址发请求，可以在preStop里调用curl -X POST localhost:8080/actuator/shutdown，但更稳的做法还是在应用内部监听ContextClosedEvent,主动触发注册中心下线。
常见退出陷阱：为什么我的Shutdown Hook没生效？
有些时候，Hook注册了，日志里也打印了“正在关闭”，但资源还是泄漏,多数情况下是这几个原因：
- 在Hook里启动了新线程，却没有
join等待，线程池清理还没执行完,JVM就退出了。 - 在Hook里调用
Thread.sleep，一旦被中断,后续清理代码被跳过。 - 多个Hook并行执行，顺序不确定，如果某个Hook依赖另一个Hook先清理,可能拿到已经关闭的资源。
- 使用
Runtime.halt()，这个方法会跳过所有Shutdown Hook,直接终结进程。
排查时，先用lsof -i :8080看端口占用，再用jstack看线程名，用jcmd <pid> Thread.print拿到更详细的栈信息，如果看到Timer或ScheduledThreadPoolExecutor还活着，就去代码里找对应的实例,在Hook里显式取消定时任务。
Q&A：关于JVM退出和资源泄漏的常见问题
kill -9和kill -15本质区别是什么？为什么推荐kill -15？
kill -9发送SIGKILL，强制内核回收进程，JVM没有机会执行任何代码，连接和文件句柄虽然由操作系统兜底释放，但应用层面的数据一致性会被打破，kill -15发送SIGTERM，JVM收到后可以执行Shutdown Hook，应用有机会完成事务回滚、连接归还和注册注销，生产环境推荐kill -15加等待时间,这是最经典的优雅退出组合。
System.exit(0)会执行Shutdown Hook吗？finally块为什么没执行？
会执行Shutdown Hook，但当前线程的finally块不会被执行，因为JVM关闭流程不会展开Java线程栈，所以资源释放逻辑不能只写在finally中，而应放在Hook或Spring的@PreDestroy方法里，如果你发现有资源没关闭，优先检查是不是把希望寄托在了finally上。
Spring Boot优雅停机和直接kill -15有什么区别？
直接kill -15触发JVM级Shutdown Hook，但Spring Boot的优雅停机还会先停止接收新请求，等待进行中请求完成，再按顺序关闭容器和Bean，因此生产环境优先开启server.shutdown=graceful，再配合JVM Hook双保险，这样既兼顾HTTP请求,也覆盖自定义资源。
优雅退出JVM不靠侥幸，而是靠机制：用SIGTERM与Shutdown Hook铺垫，用Spring Boot的优雅停机兜底，再让Kubernetes的宽限期捂住突发情况，下次遇到退出混乱时，先想想你是不是用了kill -9。