jvm不退出是因为存在活跃的非守护线程，通常是第三方线程池未关闭；可通过jstack定位，用生命周期钩子、shutdown hook或反射强制关闭，并通过健康检查预防。
主线程结束了，jvm 却卡着不退出，十有八九是第三方线程池组件在后台偷偷留了非守护线程——它没被关，jvm 就不敢走。这不是 bug，是 java 的设计逻辑：只要还有活跃的非守护线程，jvm 就必须等下去。
确认是不是线程池在“赖着不走”
先别急着改代码，用工具把现场看清楚：
- 运行 jstack
（替换为你的 Java 进程 ID），重点找 pool-*, ForkJoinPool-, ScheduledExecutor- 这类命名的线程，状态不是 TERMINATED 就是嫌疑人； - 如果看到一堆 WAITING on java.util.concurrent.ThreadPoolExecutor$Worker 或者 TIMED_WAITING (parking)，基本锁定是线程池没 shutdown；
- 注意线程是否标记为 daemon=false —— 非守护线程才是 JVM 的“绊脚石”。
从根源上切断线程池的存活依赖
第三方组件通常不暴露 shutdown 方法，但多数提供生命周期钩子或配置入口：
- 查文档看是否支持 auto-close、close-on-shutdown 或 enable-graceful-shutdown 这类开关，开启它；
- 若组件基于 Spring，检查是否被 @Bean(destroyMethod = "shutdown") 或 @PreDestroy 覆盖，手动补上销毁逻辑；
- 对纯 SDK 类型组件（如某些 HTTP 客户端内置的连接池），尝试调用其 close()、shutdownNow() 或 cleanup() 方法——哪怕文档没写，反编译或源码里常藏着；
- 实在找不到出口，可用反射强制访问私有线程池字段并调用 shutdown，仅限调试或兜底场景。
用 Shutdown Hook 做最后一道保险
即使主线程结束，JVM 关闭前仍会执行注册的钩子。这是兜底关闭线程池最稳妥的方式：
- 在应用启动早期（比如 main 方法开头或 Spring ContextRefreshedEvent 里）注册：
try {
// 调用你掌握的线程池 shutdown 方法
yourThreadPool.shutdown();
if (!yourThreadPool.awaitTermination(10, TimeUnit.SECONDS)) {
yourThreadPool.shutdownNow();
}
} catch (Exception e) {
e.printStackTrace();
}
}));
- 注意：Shutdown Hook 本身不能阻塞太久，超时后 JVM 会强行终止，所以 awaitTermination 要设合理时限；
- 避免在钩子里做 I/O、网络或锁竞争操作，防止二次卡死。
预防下次再踩坑：上线前加个线程池健康检查
别总等出事才排查。简单加一段启动后校验逻辑：
- 遍历 Thread.getAllStackTraces().keySet()，统计非守护线程数量及名称，打日志或抛告警；
- 对已知第三方线程池（如 OkHttp 的 Dispatcher、RabbitMQ 的 ConnectionFactory），封装一层包装器，在构造时自动注册 shutdown 逻辑；
- CI/CD 流水线中加入 jstack 断言脚本：启动服务 → 等待就绪 → 执行 jstack → grep “pool-” 线程数，非零则失败。
