1. 故障现场应用发布后进程一直不退1.1 现象描述上周五晚上我负责的一个后端服务做版本发布运维那边把停服脚本执行完等了好几分钟进程就是退不掉。新版本的Pod因为旧进程没释放端口一直起不来发布窗口被硬生生拖了二十分钟。最开始怀疑是JVM还有非daemon线程在干活直接jstack一把梭结果看到业务线程池里攒了一堆工作线程全部卡在WAITING状态像是被人按了暂停键。更诡异的是应用代码里明明调用了executor.shutdown()线程池却始终没走到TERMINATED状态。当时的第一反应是不是线程池的shutdown逻辑写错了查了一圈代码发现问题比想象中隐蔽。这篇文章就把这个完整排查过程拆开讲讲顺便把线程池关闭机制的几个关键点梳理清楚包括shutdown()和shutdownNow()的真实语义、阻塞队列选型对关闭行为的影响以及任务内部中断响应的重要性。如果你也遇到过类似“shutdown了但线程不结束”的情况这篇大概率能帮上忙。1.2 第一时间做了什么出问题时不要慌先收集现场信息。我先做了三件事第一jstack pid拿到完整线程Dump确认到底哪些线程还活着第二查运维脚本确认停服时调用的哪个方法第三翻代码确认线程池在Spring容器里的生命周期。这三步做完基本能定位到问题的大致范围。线程Dump里最显眼的是pool-3-thread-1到pool-3-thread-8这一批线程状态清一色是WAITING (parking)。这个信息很关键它意味着线程池的工作线程没有执行任何任务而是停在任务队列上等活儿干。按理说如果shutdown()被正确执行线程池会把空闲线程打断让它们退出。但现实是这批线程活得好好的说明线程池并没有真正进入关闭流程。注意线程Dump看出问题的方向但看不出具体的调用链原因。别急着下结论继续往下查。2. shutdown在干什么线程池关闭的底层机制2.1 线程池的七个参数和状态流转要理解shutdown为什么不生效先得把线程池的运行机制捋一遍。Java线程池的参数一共七个这也是网上的高频面试题参数含义实际影响corePoolSize核心线程数低于这个数会创建新线程maximumPoolSize最大线程数线程数上限超出后新任务进队列或触发拒绝策略keepAliveTime非核心线程空闲存活时间线程空闲超过这个时间会被回收workQueue阻塞队列决定任务堆积方式直接影响关闭行为threadFactory线程工厂决定线程名字、是否daemon等handler拒绝策略队列满且线程数到上限时的处理方式线程池内部维护着一个AtomicInteger的ctl变量高3位表示运行状态低29位表示工作线程数。状态流转是单向的RUNNING→SHUTDOWN→STOP→TIDYING→TERMINATED。关键点在于shutdown()和shutdownNow()对应着两种完全不同的状态迁移路径。我记得当时看源码时有个很直观的类比shutdown()就像公司宣布“不再接新单但已接的单子必须做完”而shutdownNow()则是“所有业务立即停没做完的直接交回正在做的强行打断”。2.2 shutdown()与shutdownNow()的本质区别这两者的差异直接决定了“shutdown失败”这个问题的答案。shutdown()做的事比较温和状态从RUNNING改为SHUTDOWN然后中断所有空闲的工作线程。注意“空闲”这个词正在执行任务的线程不会被直接打断。代码层面它对每个worker调用Thread.interrupt()但中断对于一个正在跑业务的线程来说只是一个标志位任务内部如果不检查这个标志或者不响应中断线程就根本不会停下来。另外shutdown()不会清空任务队列。如果队列里还有任务线程池依然会把它们消费完才进入真正的终止流程。这就是“线程池关闭”最常见的误解来源很多人以为shutdown等于立即停止实际上它是“等待所有任务自然完成”。shutdownNow()就不一样了状态直接改成STOP然后中断所有线程不管是空闲还是正在执行再把队列里的未执行任务全部捞出来返回给你。但它也有个局限——正在执行的任务只是收到一个中断信号如果任务内部无视中断线程照样不会退出。所以这两者的区别用表格看更清楚行为shutdown()shutdownNow()状态迁移RUNNING→SHUTDOWNRUNNING→STOP中断空闲线程是是中断运行中线程否是尝试清空任务队列否是返回未执行任务新任务提交拒绝拒绝任务必须响应中断标记否是2.3 三种常见的关不干净场景根据我对线上各种“shutdown失败”案例的观察问题基本都可以归到三类第一类线程池队列里还堆着大量任务。如果用的是无界队列比如LinkedBlockingQueue默认不设容量生产消费速度不匹配时任务会不断堆积shutdown()之后线程池依然会慢慢消费这些任务关闭时间完全不可控。这个场景在网络请求、消息消费类服务里特别常见。第二类正在执行的任务不响应中断。任务里可能调用了无法中断的阻塞方法比如synchronized锁等待、普通的Lock.lock()、InputStream.read()、Thread.sleep()虽然在Java层面可以响应中断但如果代码里捕获InterruptedException后直接吞掉了中断标志会被清除线程也停不下来。第三类线程池配置了核心线程且没有allowCoreThreadTimeOut。这种情况即使所有任务执行完了核心线程也会一直存活。虽然shutdown()会打断空闲核心线程但如果线程不响应中断或线程池没有正确走到终止逻辑同样会卡住。3. 用线程Dump和JFR锁定元凶3.1 jstack快速定位可疑线程排查线程池问题jstack是最常用的工具。但jstack的输出信息量大几百行里找到目标线程需要一点技巧。线程池的线程名称默认是pool-N-thread-M如果你的代码自定义了ThreadFactory那更好办直接搜自定义前缀就行。我当时用的是默认名字所以直接搜pool-3-thread定位到了那一组线程。pool-3-thread-1 #11 prio5 os_prio0 cpu1.32ms elapsed48236.07s tid0x00007f1d44002800 nid0x1e9e waiting on condition [0x00007f1d41df6000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(...) at java.util.concurrent.LinkedBlockingQueue.take(...) at java.util.concurrent.ThreadPoolExecutor.getTask(...) at java.util.concurrent.ThreadPoolExecutor.runWorker(...) at java.util.concurrent.ThreadPoolExecutor$Worker.run(...)看到ThreadPoolExecutor.getTask()这行就知道线程在等待队列里取任务处于空闲状态。空线程还活着说明中断没有让它们退出或者本来就没收到中断信号。elapsed字段也很有参考价值它表示线程存活时间如果这个值已经趋近于进程运行时长说明这批线程打从进程启动就一直在中途没退出过。3.2 JFR深度分析阻塞在哪个调用上jstack只能看当前瞬间的线程状态如果某些线程是“间歇性阻塞”很难仅靠Dump就还原真相。这时候用JFRJava Flight Recorder录一段事件能拿到更多上下文信息。JFR的用法很简单不用重启进程直接命令行操作jcmd pid JFR.start nameshutdown-debug duration60s filename/tmp/result.jfr settingsprofile等录制完成后再用jfr print或JMC打开文件重点看Thread Park、Java Monitor Blocked、Thread Sleep几类事件。我当时用JFR发现一个很有意思的现象线程池线程虽然大部分时间在park但每隔几十秒会短暂执行一个任务这个任务里发生了锁竞争导致另一个业务线程被阻塞进而拖住了一个核心服务的处理链路。JFR还能看到对象的持有关系比如某把锁是谁持有、谁在等锁、锁被持有了多久。这个信息在排查shutdown卡住特别管用如果线程在退出前需要获得某把锁而锁一直被另一个线程占着就永远退不出去。可惜很多人掉进这个坑时都只会盯着shutdown本身。3.3 最小复现demo为了验证思路我在本地写了一个最小复现demo。场景就是往线程池里丢一个任务任务体里对某个共享对象加synchronized锁另外一个线程长期持有这把锁不放。然后主线程调用shutdown()你会发现线程池怎么都关不了。public class ShutdownDemo { private static final Object LOCK new Object(); public static void main(String[] args) throws Exception { ThreadPoolExecutor executor new ThreadPoolExecutor( 4, 4, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(1000), new NamedThreadFactory(demo-pool), new ThreadPoolExecutor.AbortPolicy() ); // 先让一个线程持有LOCK Thread holder new Thread(() - { synchronized (LOCK) { System.out.println(holder thread acquired lock, will never release); try { Thread.sleep(Long.MAX_VALUE); } catch (InterruptedException ignored) { } } }); holder.start(); Thread.sleep(1000); // 线程池任务等待LOCK这个任务一旦被执行就会卡住 executor.execute(() - { System.out.println(task started, waiting for lock...); synchronized (LOCK) { System.out.println(task acquired lock); } }); Thread.sleep(1000); executor.shutdown(); boolean terminated executor.awaitTermination(5, TimeUnit.SECONDS); System.out.println(shutdown called, terminated terminated); executor.shutdownNow(); terminated executor.awaitTermination(5, TimeUnit.SECONDS); System.out.println(shutdownNow called, terminated terminated); } }这个demo的输出是第一次awaitTermination超时返回false第二次shutdownNow()也没有让线程退出。原因就是Thread.sleep(Long.MAX_VALUE)不会响应中断线程始终在休眠锁不释放任务线程永远拿不到锁整个线程池无法终止。注意Thread.sleep()本身是能响应中断的但如果你在catch (InterruptedException)里不处理也不恢复中断标志外部的中断请求就形同虚设。4. 根因分析队列、任务与中断的三角关系4.1 阻塞队列选择带来的隐患排查到这一步根因逐渐浮出水面。我们服务里的线程池用的是new LinkedBlockingQueue(10000)表面上是个有界队列但这个“界”设得其实不合理——10000的容量意味着最多可以有1万个任务积压。如果每个任务的执行时间是秒级光消费这些积压任务就得几个小时。更麻烦的是我们的corePoolSize设置的也不合理。当时配置的同学可能是照着“最大线程数 JVM可用CPU数”的思路来但实际业务里大量任务都是IO等待线程该加没加任务全堆在队列里排队。这里展开聊一下阻塞队列的选型。常见三类队列特点对shutdown的影响LinkedBlockingQueue默认无界或指定容量任务会一直积压shutdown后消费不完ArrayBlockingQueue固定容量先进先出容量可控但队列满后会触发拒绝策略SynchronousQueue不存任务直接交接给线程只要线程接得住不会积压但线程不够就丢任务如果选SynchronousQueue任务不会积压在队列里shutdown()只要等正在执行的任务结束就行时间相对可控。缺点是吞吐量受线程数限制容易触发拒绝策略。我们当时为了“不丢任务”选了无界队列结果就是关闭时被积压任务拖死。4.2 任务内部不响应中断才是硬伤队列积压只是雪上加霜真正让shutdown彻底失效的是任务内部不响应中断。回顾一下shutdown()对运行中任务的态度发一个中断请求但任务不能中断自己线程池绝不会强行杀掉线程。所以任务里如果调用了synchronized同步块等待锁或者用了Lock.lock()不响应中断的锁API又或者在三方SDK内部阻塞在网络IO上中断信号都会被无视。我们当时定位到的一个典型任务长什么样它在内部调用了一个HTTP客户端而客户端的连接池把超时时间设成了120秒。任务在服务停机时正好被卡在一个慢请求上线程池发中断信号时HTTP客户端的连接等待根本不理这个信号。一个任务卡120秒队列里还有几十个类似任务流水式地卡最后等于整个线程池用“龟速”消耗完积压任务整个进程就迟迟不退。这其实是很多“线程池shutdown失败”案例的共同特点shutdown本身没问题问题出在任务逻辑对中断信号不敏感。4.3 从这里看配置还踩了哪些坑排查过程中我还发现线程池的keepAliveTime和最大线程数配置也存在坑。keepAliveTime只对非核心线程生效核心线程即使空闲也会一直存活除非显式开启allowCoreThreadTimeOut(true)。很多团队的规范都会说“核心线程不要回收”但并没有说为什么。实际上如果不设置allowCoreThreadTimeOut即使线程池调用了shutdown()空闲的核心线程也需要依赖中断机制来退出。如果线程身上恰好带着不可中断的阻塞调用这线程就永远退不干净。还有一点是关于“线程池设置最大线程数是jvm剩余可用线程”的说法。这种说法严格来说不准确JVM并没有所谓“剩余可用线程”的概念线程池的最大线程数是根据任务类型和资源量来定的。CPU密集型任务一般设置为核心数1IO密集型任务可以设置为核心数的两倍或更高。盲目照搬一个公式不如结合压测数据和任务耗时分布来定。实操心得线程池关闭出问题八成不是shutdown代码的问题而是队列、任务、线程三者的组合出了问题。排查顺序建议是先看线程Dump再倒查任务队列长度最后审查任务内部对中断的处理。5. 优雅停机的正确落地姿势5.1 标准关闭代码模板踩过这次坑之后我把服务里的线程池关闭逻辑统一改成了下面这个模板public boolean shutdownExecutor(ThreadPoolExecutor executor, String poolName, long timeout, TimeUnit unit) { // 停止接收新任务等待已提交任务完成 executor.shutdown(); try { if (!executor.awaitTermination(timeout, unit)) { // 超时未终止尝试强制中断 executor.shutdownNow(); if (!executor.awaitTermination(timeout, unit)) { // 强制中断后依然没退出记录日志或上报告警 System.err.println(pool poolName failed to terminate after force shutdown); return false; } } } catch (InterruptedException e) { // 当前线程被中断重新强制中断 executor.shutdownNow(); Thread.currentThread().interrupt(); return false; } return true; }模板分三步先shutdown()等任务自然完成给一段合理的缓冲时间超时后shutdownNow()强制中断最后再给一段缓冲时间还不退就说明任务对中断无响应这时候必须人工介入。这个模板看着简单但里面有一个容易忽略的点awaitTermination期间如果当前线程被打断比如应用的老爷车停机脚本用了超时控制一定要在catch块里再次调用shutdownNow()并Thread.currentThread().interrupt()恢复中断标志。否则会出现线程池没人管、调用方也不知道的尴尬局面。5.2 任务侧如何配合光改线程池关闭逻辑是不够的任务内部也得配合。不管是自研代码还是调用三方SDK只要任务是可中断的就必须正确处理中断信号。几个基本原则不要捕获InterruptedException后直接吞掉至少要Thread.currentThread().interrupt()恢复标志位使用Lock.lockInterruptibly()替代Lock.lock()尤其在可能长时间等待锁的场景下在循环体里检查Thread.currentThread().isInterrupted()发现中断就主动退出对无法立即取消的IO操作设置更短的超时时间避免被单个慢请求拖死另外我之前一直没意识到的一点是shutdown()之后的线程池拒绝新任务会抛出RejectedExecutionException。如果你在停机脚本里还会向线程池提交任务比如清理类任务记得在提交处捕获这个异常否则会打出一堆吓人的错误日志误导排查方向。5.3 是否需要设置daemon线程关于设置ThreadFactory把线程标记为daemon的建议网上经常能看到但我个人持保留态度。把线上业务的线程池线程设置成daemon确实能让JVM在关闭时更快退出不用等所有线程结束。代价是daemon线程在JVM退出时会被直接抛弃如果线程正在执行关键任务比如写日志、刷缓存这些操作可能中途夭折数据一致性受损失。我的建议是分场景纯后台的定时清理、监控上报类线程池可以设成daemon无伤大雅但是处理业务请求的线程池不要设daemon应该用非daemon线程配合优雅停机流程保证任务真正被处理完或安全取消。注意daemon线程不等于“能随意kill”它只是JVM退出时不拦路不代表任务可以安全丢弃。任何daemon线程里都不应该放不可恢复的、需要持久化的操作。6. 复盘那些值得写进规范里的经验6.1 检查清单这次排查之后我在团队内部沉淀了一个线程池关闭自查清单分享出来供参考检查项说明建议关闭方法选择直接shutdown还是shutdownNow优先shutdownawaitTermination超时再shutdownNow队列容量队列上限是否合理根据任务峰值和可接受的最大延迟来定不要盲目设大任务中断响应是否响应中断信号任务里长阻塞环节全部改为可中断形态awaitTermination等待时间是否设置了合理超时建议至少30秒以上不宜过短阻塞IO超时三方调用的超时时间独立于业务超时建议单独设置网络层超时线程命名是否自定义ThreadFactory必须命名否则排障时很难定位关闭入口关闭逻辑是否在停机钩子里Spring环境注意顺序先停流量再关线程池这里面最容易被忽略的是“关闭入口”。很多服务用Spring治理而Spring容器关闭时会自动调用PreDestroy方法如果你在别处又手动调了一次executor.shutdown()第二次调用是幂等的不会报错但很容易造成第一次shutdown后任务还在跑、第二次已经不让提交的混乱状态。规范做法是线程池的shutdown只在容器销毁阶段处理统一入口不要分散在业务代码里。6.2 相关热词的延伸理解几个热搜词和这次排查关系很紧密我顺带展开说说。“线程池的阻塞队列选择”——上面已经讲了队列对关闭行为的影响这里再补充一点如果你用的是有界队列拒绝策略也要想清楚。默认的AbortPolicy会直接抛异常有可能在业务高峰期制造一堆错误日志CallerRunsPolicy则是把任务交还给提交线程执行降低吞吐但保住任务不丢DiscardPolicy和DiscardOldestPolicy是默默丢弃适合不重要的任务。拒绝策略的选择影响的不只是运行时也影响关闭阶段的容错。“线程池配置”——配置的核心不是死记参数而是搞清楚每种任务的执行特点。我当时给团队定过一个原则核心线程数按“80%水位下的平均并发数”估最大线程数按“压测出性能拐点的并发数”定队列长度为“最大线程数未覆盖的那部分突发流量的缓冲量”。这个说法不追求精准但远比拍脑袋强。“线程池设置最大线程数是jvm剩余可用线程”——再强调一次这个说法不准确。线程不是无限便宜的每个线程默认栈大小1MB左右64位JVMx86下约1MB如果一口气开几千个线程光栈内存就占好几个GBGC和上下文切换开销也会爆炸。最大线程数的上限应该由“内存预算 / 每个线程的栈内存 系统承受能力”共同决定而不是“JVM还能剩几个线程”。“线程池的七个参数”——网上凡是讲线程池的都会讲这七参数大家背得滚瓜烂熟但很多人不知道ThreadPoolExecutor还有几个“隐藏”开关比如allowCoreThreadTimeOut、prestartAllCoreThreads、removeOnCancelPolicy。这些开关在特定场景下很重要比如allowCoreThreadTimeOut(true)可以让核心线程也按keepAliveTime回收对关闭逻辑的稳定性有正向作用。“c线程池”——这个主要是跨语言对比。C的线程池和Java的线程池思路相似但C没有内置的ThreadPoolExecutor通常基于std::thread、std::condition_variable和队列手动实现。C里更没有shutdown()这种有标准语义的API大部分实现就是设置一个停止标志然后通知所有线程退出。这引出一个更本质的问题线程池关闭是“协作式”的不是“强杀式”的语言层面给你再好的工具也得靠任务代码配合。6.3 一点个人体会整个排查过程前后花了大概三个小时最后定位到的根因说出来其实也不复杂任务内部有一个不可中断的锁等待恰好又赶上停机时任务队列有积压shutdown()按设计好的方式慢慢等任务完成结果就是进程迟迟不退。最让我印象深刻的不是代码本身的问题而是“shutdown失败”这个说法本身就有误导性。线程池的shutdown机制从来没有承诺过“立即停止所有线程”它只承诺“开始停止流程”。如果任务内部不配合流程就走不完。这和很多人理解中的“关闭”是两码事。所以我对团队的要求是所有线程池的关闭代码必须走统一模板所有长时间运行的任务必须响应中断。这不是过度设计而是我们线上这次故障换来的教训。停服不是开发时随手写个shutdown就完事它是整个应用生命周期里最难做对的一环建议有条件的团队把停机流程也纳入压测范围毕竟线上可没有那么多“周五晚上”用来慢慢排查。