多线程程序最让人头疼的不是跑不起来而是跑着跑着就不动了。进程还在端口还连着CPU 曲线平得像一条直线日志停在某个时间点之后再没吐过一个字重启一下立刻恢复正常过几个小时又来一遍。这种假活状态我见过太多次了线上出故障的时候团队第一反应往往是去看 CPU、看内存、看磁盘结果查了一圈发现全都正常最后才意识到是线程卡死了。多线程卡死问题排查起来折腾人的地方就在于它不像崩溃那样给你一份堆栈告诉你哪里挂了它就是安安静静地堵在那里什么都不做也不报错。这篇文章我想把这么多年踩过的坑一次性捋清楚。内容主要围绕一个核心问题展开多线程程序为什么会卡死以及遇到卡死之后怎么快速定位、怎么从根上治掉。不管你是写 Java 后端、C 服务、Python 数据处理脚本还是搞客户端和 Flutter 的异步任务思路都是通的。文章会给出四套可以落地的应对方法从线程栈抓取、锁治理、线程池容量设计到阻塞点治理每一套我都会讲清楚为什么这么做、具体怎么操作、有哪些容易翻车的细节。适合已经写过并发代码但被卡死问题折磨过的同学也适合刚接手线上服务想提前做防御的人。1. 多线程卡死到底是什么先把问题定义清楚很多人一张口就说死锁了其实卡死和死锁不完全是一回事。死锁是卡死的一种特例卡死的范围要大得多。我习惯把卡死的表现分四类分类的意义在于不同类别的排查手段完全是两套逻辑混在一起查只会浪费时间。第一类是经典死锁。线程 A 拿着锁 1 等锁 2线程 B 拿着锁 2 等锁 1两边都不撒手永远等下去。这类问题的特征是线程栈里能看到明确的waiting to lock或者futex_wait而且是一组线程互相指向对方形成闭环。第二种是活锁。线程都在跑CPU 也不低但没有任何一个任务真正推进比如两个线程互相让步反复重试或者 CAS 一直失败自旋。活锁比死锁更隐蔽因为它看起来很忙。第三种是线程饥饿。锁被某个长任务一直占着或者线程池被少数几个慢请求全部占满后面的任务排不上队。第四种是阻塞堆积也可以叫资源耗尽型卡死。线程没死也没锁冲突就是卡在某个外部依赖上比如数据库连接拿不到、HTTP 调用没设超时、往一个满队列里塞任务。这种最容易误判因为栈上是清一色的socketRead0或者park。把这四类分清楚之后你会发现一个共同点卡死的本质是某个线程在等一个永远等不到的东西。要么等锁、要么等资源、要么等一个不会返回的调用。所以排查卡死的核心动作就一个——找到所有线程此刻在等什么。这个问题一旦回答清楚八成的问题当场就能定位。1.1 为什么多线程程序特别容易假活单线程程序一旦卡住通常是明确的——要么在跑要么挂了。多线程不一样它是一部分线程死了另一部分线程还在装模作样地活着。心跳线程可能还在每秒报告一次健康状态因为它走的是独立线程、不碰业务锁监控线程还在采集指标因为它只读不写。对外表现就是服务在线但不可用从负载均衡的视角看它是健康的流量照样往里打于是越来越堵。这个特性决定了一件事健康检查不能只检查进程存活一定要检查业务线程池的可用容量。我个人习惯在健康检查里加一项空闲业务线程比例一旦空闲线程低于总容量的 10% 且持续 30 秒就直接把实例拉出集群。这比等到请求超时堆积再报警要早得多很多卡死事故如果早点摘流量根本不会扩散成全局故障。1.2 排查前必须先准备好的三份信息很多人卡死之后第一反应是重启重启确实能恢复但也把现场毁了。我现在的习惯是重启之前必须把现场抓下来而且是有准备地抓。有三份信息是排查的前提缺一个都会让后续分析变得很痛苦。进程 PID 和线程命名规范。给线程起名字这件事看起来是小事但在排查的时候价值巨大。一个叫order-timeout-checker的线程和一个叫pool-3-thread-7的线程在栈里能提供的线索完全不是一个量级。JDK 里用ThreadFactoryBuilder().setNameFormat()C 里用pthread_setname_np()Python 里在threading.Thread(name...)里给上成本极低收益极高。最近一次变更的时间点。卡死往往不是新问题而是被某个变更触发的。线程池参数从有界改成无界、某个接口新增了一次远程调用、锁的范围被顺手扩大了一圈这些都是导火索。把变更记录和故障时间对齐能省掉一大半的猜测。可用的诊断工具。Java 场景要能执行jstack和jcmdC 场景要能 attachgdb或者 preload 一个信号处理Python 场景最好提前装好py-spy。这些工具临时装往往来不及尤其是生产环境权限卡得很死的时候。提示养成在发版时顺手确认诊断工具可用性的习惯比出事之后再申请权限靠谱得多。我见过太多次因为生产环境没装gdb、py-spy装不上最后只能靠猜和重启。2. 第一招线程栈快照定位法遇到卡死我的第一反应永远是抓线程栈而且要连续抓几次。这是四招里最基础也最有效的一招能解决大部分我完全不知道卡在哪的场景。原理很简单线程栈告诉你在这一刻每个线程在执行什么、在等什么锁、持有哪个锁。一次快照能看出静态的等待关系多次快照能看出哪些线程是卡住不动的哪些只是恰好路过。为什么强调连续抓因为单次快照会骗人。一个线程可能正好停在一个正常的方法调用上但如果你隔 5 秒再抓一次发现它还停在同一行、同一个栈帧那基本可以确定它就是卡住的那一个。我一般的做法是抓 3 次间隔 5 到 10 秒然后做差集。三次都出现在同一个位置的线程就是嫌疑最大的。2.1 Java 场景下 jstack 的用法和解读Java 生态里最顺手的就是jstack。命令门槛很低# 抓取线程栈快照-l 会额外输出锁的持有关系 jstack -l pid stack_1.txt # 如果需要更详细的信息可以配合 jcmd jcmd pid Thread.print -l stack_2.txt很多人只知道jstack能打栈不知道-l参数会附带Locked ownable synchronizers和waiting to lock的信息而这才是定位死锁的关键。抓下来之后怎么读我一般按这个顺序看观察点说明常见线索线程状态统计栈文件开头会给出各状态的线程数量大量 BLOCKED 说明锁竞争严重大量 WAITING 说明在等待条件相同栈帧多个线程停在同一个方法大概率是锁竞争或者线程池耗尽锁持有关系谁持有锁、谁在等这把锁形成环就是死锁native 帧socketRead0、futex_wait指向 IO 阻塞或底层锁等待Java 还有一个很好用的命令是jstack -F配合jcmd的Thread.print在jstack因为 safepoint 卡住的时候能救急。另外提一句JDK 自带的jconsole和jvisualvm也有检测死锁按钮但生产环境一般不方便开图形界面命令行还是主力。注意jstack依赖 JVM 到达安全点safepoint。如果某个线程在跑一个巨大的无 safepoint 循环jstack可能会挂住几秒甚至几十秒。这时候用jcmd pid Thread.print会更稳一点实在不行才考虑jstack -F。2.2 C/C 场景用 gdb 批量抓栈C 没有 JVM 那套现成的工具得靠gdb。基本玩法是 attach 上去然后对每个线程打 backtrace# 非交互式抓取所有线程的调用栈 gdb -p pid -batch -ex thread apply all bt gdb_stacks.txt # 如果有调试符号加上 -ex thread apply all bt full 能看到更多局部变量 gdb -p pid -batch -ex set pagination off -ex thread apply all bt full gdb_full.txtthread apply all bt这一句是核心它会把所有线程挨个打印一遍调用栈。C 场景下最常见的卡死信号是pthread_mutex_lock、pthread_cond_wait、futex这几个符号看到大量线程堆在futex_wait上基本就是锁的问题。还有一个非常好用的办法是用 gdb 打印互斥锁的持有者比如pthread_mutex_t结构里能看到__owner字段直接告诉你谁拿着这把锁不放。C 还有个坑要提前说发布版本如果没带调试符号抓出来的栈全是地址等于白抓。所以我的习惯是发布时保留一份带符号的二进制和对应的 core 文件需要的时候用gdb binary core去还原符号。这个投入在排查卡死的时候回报率极高。2.3 Python 场景的 py-spy 与 faulthandlerPython 因为 GIL 的存在卡死问题有它自己的味道。纯 CPU 计算的多线程在 Python 里其实是被 GIL 串行化的真正容易卡死的是 IO 和锁的组合。诊断工具我个人首选py-spy因为它不需要侵入代码、不需要重启直接 attach# 实时抓取所有线程栈 py-spy dump --pid pid # 每秒采样一次持续 10 秒用来观察哪些栈帧反复出现 py-spy top --pid pidpy-spy dump的好处是能把每个线程的 Python 栈和 C 栈都打出来GIL 的持有者也会标出来。另一个零成本方案是在进程里提前埋faulthandlerimport faulthandler # 在启动时注册10 秒后如果还有卡住的情况就把所有线程栈打到文件 faulthandler.dump_traceback_later(10, repeatFalse, fileopen(traceback.log, w))这个方案的价值在于它不需要你手动触发进程一旦卡住超时后自动把现场落到文件里尤其适合那种人还没上机器、服务已经挂了的凌晨故障。实操心得Python 里很多卡死其实是死在socket的默认超时上。requests如果不显式设timeout它默认是无限等待的。我现在的规矩是任何网络调用必须有 timeoutrequests.get(url, timeout(3, 10))这种连接和读取分开设的写法才是标准动作。3. 第二招锁顺序与加锁粒度治理抓完栈定位到锁接下来就是治理。锁引起的卡死绝大多数都能归到两个原因加锁顺序不一致和锁的范围太大。这一招的核心思路是把锁的获取顺序全局统一同时把锁的粒度尽可能缩小。3.1 死锁的四个必要条件怎么破教科书上讲死锁有四个必要条件互斥、持有并等待、不可剥夺、循环等待。这四个条件只要破掉一个死锁就成立不了。实际工程里最容易破的是循环等待也就是统一加锁顺序。为什么选它因为互斥是共享资源的天性改不掉不可剥夺意味着要支持锁的强制释放实现复杂还容易出错持有并等待可以通过tryLock缓解但会引入重试逻辑。相比之下统一锁顺序是纯约定层面的改动成本最低、收益最直接。具体怎么做给所有的锁分配一个全局唯一的序号任何线程在需要多把锁的时候必须按序号从小到大获取。比如锁 A 编号 1、锁 B 编号 2那么所有地方都必须是先拿 A 再拿 B绝不能反过来。这样就不可能出现A 等 B、B 等 A的环。序号可以用枚举、可以用对象 hash甚至可以用字符串排序关键是全局唯一且稳定。3.2 统一锁顺序的落地方法光有约定不行得让约定变成代码里能落地的东西。我通常用两层保障一层是封装加锁方法一层是静态检查。封装的做法是把按序加锁变成一个工具方法业务代码不直接调lock()而是调封装好的lockAll(lockA, lockB)。这样加锁顺序由工具方法统一处理业务方无所谓传参顺序。// 思路示意把多把锁排序后再依次获取 public static void lockAll(ReentrantLock... locks) { // 按锁的全局编号排序保证任何调用点顺序一致 Arrays.sort(locks, Comparator.comparingInt(LockUtil::getId)); for (ReentrantLock lock : locks) { lock.lock(); } } public static void unlockAll(ReentrantLock... locks) { // 解锁顺序无所谓但好的习惯是逆序释放 for (int i locks.length - 1; i 0; i--) { locks[i].unlock(); } }静态检查那层可以用阿里开源的p3c之类的规则插件或者干脆在 code review 清单里加一条涉及多把锁的地方检查是否走封装。我个人的经验是光靠人盯一定会漏尤其是团队人数上来之后必须有工具或者准入门槛兜底。3.3 tryLock 超时给等待加一条退路统一锁顺序解决的是同时要拿多把锁的场景但还有一种情况是单把锁被长期占用导致的饥饿。这种时候tryLock配合超时就是标配。核心逻辑是等待超过阈值就放弃把已经拿到的锁放掉让别的线程有机会推进。// 带超时的加锁拿不到就放弃避免无限等待 if (lock.tryLock(500, TimeUnit.MILLISECONDS)) { try { // 临界区逻辑 } finally { lock.unlock(); } } else { // 拿不到锁走降级逻辑或抛出可重试异常 throw new RetryableException(acquire lock timeout); }这里有个细节很多人忽略tryLock失败之后不要立刻原地自旋重试那会变成活锁。正确做法是退出来交给上层做退避比如 sleep 一个随机时间再试或者干脆走降级路径。另外tryLock拿到锁之后的业务逻辑如果有嵌套加锁一定要保证嵌套的那层也能快速失败不然超时保护等于没有。3.4 锁粒度、读写锁和无锁结构的取舍锁用对了顺序还不够粒度也很关键。我见过最典型的反面案例是有人在synchronized块里做了一次 HTTP 调用。这个锁一旦被远程调用的超时拖住所有等它的线程全废。原则很简单——锁里只做内存操作任何 IO、任何远程调用、任何可能阻塞的动作都必须搬到锁外面。再具体一点读写锁的选择也有讲究。ReentrantReadWriteLock在读多写少的场景确实能提升并发度但它有个隐患写饥饿。如果读请求一直不断写线程可能长时间拿不到锁。JDK 8 之后StampedLock在部分场景表现更好但它的 API 更复杂且不支持重入用错了会死得很惨。我的建议是先评估读写比例如果写操作占比超过 10%老老实实用普通互斥锁别为了那点理论上的并发收益引入复杂度。至于无锁结构ConcurrentHashMap、AtomicLong、LongAdder这些在高并发计数和缓存场景非常成熟能替换掉大量不必要的锁。但要注意无锁不等于没成本CAS 在竞争激烈时会自旋消耗 CPU用之前最好压测一下。提示有一种特别隐蔽的锁——类加载锁和静态初始化锁。两个线程互相触发对方类的静态初始化就可能卡在一起。排查的时候如果栈上出现clinit或者Class.forName要高度警惕。4. 第三招线程池与任务队列的容量设计线程池是卡死的重灾区而且它的卡死往往最安静——线程都老老实实待在池子里既没死锁也没报错就是任务排队排不动了。这一招的核心是让线程池的参数有据可依让队列有界让任务能快速失败。4.1 线程池耗尽的隐蔽链路先说一个我印象很深的案例因为它完整展示了卡死不一定是锁的问题。一个订单服务所有接口共用一个线程池某天开始偶尔超时。查栈发现大量线程堆在调用第三方支付接口上。原因是一个新上线的功能在业务线程里同步调用了一个响应很慢的外部接口没设超时这批请求把线程池全部占满其他接口的请求只能排队。表现就是明明不相关的查询接口也开始超时。这条链路的隐蔽之处在于调用方看不出任何异常它只是慢慢到超时。线程池本身没有任何错误日志队列满了才会打印拒绝而队列如果设置得很大比如无界队列连拒绝都不会发生只会无限堆积然后 OOM。所以第一个结论是队列必须有界。4.2 线程池参数怎么算才靠谱线程池的核心参数里最容易拍脑袋的就是核心线程数和最大线程数。业界有个经验公式虽然不是绝对准确但作为起点很好用CPU 密集型任务核心线程数 CPU 核数 1。加 1 是为了在某个线程偶尔缺页或者被调度打断时CPU 不至于空闲。IO 密集型任务核心线程数 CPU 核数 × 2或者更激进一点用 CPU 核数 / (1 - 阻塞系数) 来算。阻塞系数是任务中阻塞时间占总时间的比例比如一次任务里 90% 时间在等 IO那线程数可以开到核数的 10 倍左右。任务类型核心线程数参考队列策略拒绝策略建议CPU 密集核数 1有界小队列AbortPolicy快速失败IO 密集核数 × 2 起按阻塞系数上探有界中等队列AbortPolicy 或 CallerRuns混合型拆成两个池分别配置各自有界分开的拒绝策略这里要特别提醒一个坑CallerRunsPolicy会阻塞调用方线程。它在很多场景下确实能起到背压的作用但如果调用方是 Tomcat 的工作线程或者 Dubbo 的业务线程这个策略会让调用方线程被任务占住反而加剧卡死。我一般只在后台批处理任务里用它Web 请求链路上优先用AbortPolicy配合降级。4.3 父任务等子任务那个经典的线程池死锁这是线程池卡死里最经典的一种也是面试的高频题。场景是一个任务被提交到线程池它在执行过程中又提交了子任务到同一个线程池然后阻塞等待子任务的结果。如果线程池里所有线程都在跑父任务、都在等子任务而子任务因为没有空闲线程永远排不上队整个池子就锁死了。解决办法有几个优先级从高到低不要用同一个线程池。父任务和子任务用隔离的两个池父任务池的线程不会被自己的子任务阻塞。用ForkJoinPool。它的工作窃取机制本质上能让等待子任务的线程去干活天然规避这个问题。拆解任务直接把子任务逻辑内联。如果子任务本来就是父任务的一部分、没有并发必要直接同步执行最省事。我个人的偏好是方案一因为最直白、最容易在代码里看出来。方案二虽然优雅但ForkJoinPool自己的坑也不少比如阻塞时对线程数的估算团队不熟的话不如隔离池稳。4.4 隔离与降级别让一个慢依赖拖垮全部线程池治理的最后一步是按业务隔离。把所有任务塞进一个大池子是最省事也最危险的做法。我的标准动作是核心接口一个池、非核心接口一个池、异步通知一个池、定时任务一个池。池与池之间不共享线程某个池被打满不会波及别人。隔离之外还要配降级。降级不是等出事了再想而是提前设好接口失败率超过阈值自动降级、线程池队列占用超过 80% 触发限流、慢调用比例超标触发熔断。这些机制在手写代码里能实现用成熟框架比如 Sentinel、Resilience4j 也行。关键不是工具而是有没有在关键链路上埋这些开关。实操心得给线程池起名字这件事在线程池场景下比单线程更重要。new ThreadPoolExecutor(...)一定要传一个自定义的ThreadFactory把池名和业务名编进去比如order-pay-pool-1。出问题抓栈的时候你一眼就能看出是哪个池、哪个业务卡住了。5. 第四招资源等待与阻塞点治理前三招处理的是锁、线程池和栈定位这最后一招处理的是最容易被忽略、但也最普遍的一类——阻塞在外部资源上。这类卡死的特征是没有锁竞争、线程池参数也合理但线程就是卡在某个系统调用上回不来。5.1 超时全覆盖任何可能阻塞的操作都要有超时这一点说起来简单做起来最容易漏。要覆盖的地方包括网络调用HTTP 客户端的连接超时和读取超时Socket 的SO_TIMEOUTRPC 框架的超时配置。这种一定要坐实HttpClient的connectTimeout和responseTimeout分开设只设一个等于没设。数据库连接池的获取连接超时、语句执行超时、事务超时、锁等待超时。以 HikariCP 为例connectionTimeout默认 30 秒validationTimeout默认 5 秒这些都要根据业务实际情况调别用默认值。锁前面说的tryLock超时。队列操作BlockingQueue.take()和put()都是无限的用offer()和poll()带超时的版本替代。CountDownLatch.await()和CyclicBarrier.await()这两个都提供了带超时的重载务必用带超时的那个。这里我特别想强调Java 里future.get()不带超时这个坑。它会让调用线程一直等下去而且不会响应中断之外的任何信号。正确的写法是future.get(3, TimeUnit.SECONDS)超时了抛TimeoutException走降级。5.2 连接池与外部依赖的治理数据库连接池和 HTTP 连接池是两大卡死源头因为它们都有有限资源 无限等待的组合。连接池的核心参数有四个最大连接数、最小空闲连接、获取连接超时、连接最大存活时间。最大连接数不是越大越好——数据库本身的连接数是有上限的业务侧连接池加起来超过数据库上限反而会互相挤兑。一个常见的误判是连接池不够用的时候很多人第一反应是加大最大连接数。但如果瓶颈在数据库端比如慢查询占用连接不释放加大连接数只会让数据库更慢最后雪崩。正确的做法是先看连接被谁占着、占多久定位到慢查询再优化最后才谈扩容。HTTP 连接池也是同理。maxConnections、maxConnectionsPerHost、connectionRequestTimeout这几个参数要成套配置。尤其是在微服务调用链里一个服务调用超时会在链路上放大上游的连接池被拖垮然后继续往上传。5.3 那些不起眼但会咬人的阻塞点除了网络和数据库还有几个隐蔽的阻塞点值得单独提日志同步锁。同步写日志在高并发下会成为瓶颈尤其是磁盘慢的时候。用AsyncAppender能缓解但要注意它的队列满了之后的行为——默认是丢弃还是阻塞得看清楚。synchronized触发的偏向锁撤销。这个属于 JVM 层面的细节正常情况下不会导致卡死但在极端竞争下synchronized的膨胀过程会有开销。JDK 15 之后偏向锁已经默认禁用这个坑新一代的开发者基本遇不到了。System.gc()引起的全停顿。有人在代码里手动调System.gc()在高并发下会引发一次次长停顿看起来像卡死。这种问题抓栈是抓不到的得看 GC 日志。文件锁。多进程或者多线程同时读写同一个文件如果没处理好文件锁也会卡住。这种在嵌入式或者数据处理场景更常见。注意查不到锁、查不到线程池问题的时候一定要去看 GC 日志和系统层面的iostat、vmstat。卡死的原因可能根本不在你的代码里而在系统资源被耗光上。5.4 监控埋点把卡死掐死在萌芽所有治理手段里最省心的其实是提前发现。等用户投诉再来查损失已经造成了。我现在的标配是三类监控线程池指标活跃线程数、队列长度、已完成任务数、拒绝次数。后台把这些指标打点到监控系统设置合理的告警阈值。锁指标可以用 JMX 的ThreadMXBean.findDeadlockedThreads()定期检测死锁也可以用 Micrometer 之类的库采集锁等待时间。检测到死锁直接告警加 dump 现场。慢调用指标每个外部调用的 P99 延迟一旦超过阈值就告警。卡死往往是慢调用累积的结果慢调用了就能提前预警。// 定期检测死锁并 dump 现场这个定时任务本身要用独立线程 ThreadMXBean mxBean ManagementFactory.getThreadMXBean(); long[] deadlocked mxBean.findDeadlockedThreads(); if (deadlocked ! null deadlocked.length 0) { ThreadInfo[] infos mxBean.getThreadInfo(deadlocked, true, true); // 这里做告警 落盘方便事后分析 }findDeadlockedThreads只覆盖经典死锁检测不到线程池耗尽和资源阻塞所以它只是监控的一部分不能只靠它。6. 常见问题速查与避坑清单前面四招讲的是方法和原理最后这部分我想把排查过程中最常遇到的问题整理成一张速查表方便现场对号入座。这些都是我自己遇到过或者帮同事排查过的真实场景比泛泛的理论更有指向性。6.1 卡死问题速查表现象可能的根因快速验证方式处理方向多个线程状态为 BLOCKED栈上互相等锁死锁或锁竞争jstack -l看锁环findDeadlockedThreads统一锁顺序缩小锁粒度线程全在socketRead0/futex_wait外部依赖阻塞无超时看调用栈的类名确认调用目标加超时调用移出锁线程池活跃数打满队列持续增长慢任务占满线程看线程池指标和任务栈隔离线程池队列设界降级CPU 高但任务不推进活锁或 CAS 自旋看火焰图定位自旋点退避重试限制自旋进程停顿、栈抓不出来GC 长停顿或 safepoint看 GC 日志排查内存泄漏调 GC 参数Python 进程卡住无响应GIL 被占或 socket 阻塞py-spy dump换多进程加 timeout父任务等子任务永远不返回同一线程池嵌套提交看栈上有无同类submit帧拆分线程池或用 ForkJoinPool这张表不能覆盖全部情况但它覆盖了日常遇到的 80%。真正现场排查的时候我的顺序是先看状态统计、再看相同栈帧、最后看锁和资源这个顺序能让大部分问题在十分钟内有个方向。6.2 几个容易踩的坑最后说几个我觉得最值得记下来的经验点。第一别急着重启。卡死现场是最宝贵的信息重启之后就没了。养成先 dump 后重启的肌肉记忆哪怕只是抓一份jstack也比什么都没有强。第二卡死往往是阈值问题而不是逻辑错误。很多多线程程序在低并发下完全正常一到高并发就卡逻辑上没毛病就是参数设计得太紧。线程池小、超时长、队列大随便一个都可能在压力下变成卡死。压测一定要在接近生产流量的规模下做小流量的压测看不出这些问题。第三卡死和性能问题经常是一回事的两面。一个请求从 50ms 变成 5s看起来是性能问题但它可能持续占着线程和锁最后演变成卡死。所以慢调用治理和卡死治理本质上是一套功夫监控指标也应该统一起来看。第四写并发代码的时候,多问自己一句这个等待有没有上限。每一个wait、get、await、take、read都要能回答如果它永远不返回我会怎么样。回答不上来的地方就是将来的事故点。我在实际使用中的体会是多线程卡死从来不是某一个灵丹妙药能一次性解决的它考验的是整个链路上每一个等待点的设计是否合理。你把这篇文章里的四招吃透——栈定位、锁治理、线程池容量、阻塞点治理——再加上平时的监控埋点和压测习惯大部分卡死问题都能在它造成大范围影响之前被拿下最少也能在故障发生时快速定位到根因。真正难的不是修而是知道去哪里看、看什么。
多线程卡死排查与治理：四招定位死锁、线程池与阻塞点
多线程程序最让人头疼的不是跑不起来而是跑着跑着就不动了。进程还在端口还连着CPU 曲线平得像一条直线日志停在某个时间点之后再没吐过一个字重启一下立刻恢复正常过几个小时又来一遍。这种假活状态我见过太多次了线上出故障的时候团队第一反应往往是去看 CPU、看内存、看磁盘结果查了一圈发现全都正常最后才意识到是线程卡死了。多线程卡死问题排查起来折腾人的地方就在于它不像崩溃那样给你一份堆栈告诉你哪里挂了它就是安安静静地堵在那里什么都不做也不报错。这篇文章我想把这么多年踩过的坑一次性捋清楚。内容主要围绕一个核心问题展开多线程程序为什么会卡死以及遇到卡死之后怎么快速定位、怎么从根上治掉。不管你是写 Java 后端、C 服务、Python 数据处理脚本还是搞客户端和 Flutter 的异步任务思路都是通的。文章会给出四套可以落地的应对方法从线程栈抓取、锁治理、线程池容量设计到阻塞点治理每一套我都会讲清楚为什么这么做、具体怎么操作、有哪些容易翻车的细节。适合已经写过并发代码但被卡死问题折磨过的同学也适合刚接手线上服务想提前做防御的人。1. 多线程卡死到底是什么先把问题定义清楚很多人一张口就说死锁了其实卡死和死锁不完全是一回事。死锁是卡死的一种特例卡死的范围要大得多。我习惯把卡死的表现分四类分类的意义在于不同类别的排查手段完全是两套逻辑混在一起查只会浪费时间。第一类是经典死锁。线程 A 拿着锁 1 等锁 2线程 B 拿着锁 2 等锁 1两边都不撒手永远等下去。这类问题的特征是线程栈里能看到明确的waiting to lock或者futex_wait而且是一组线程互相指向对方形成闭环。第二种是活锁。线程都在跑CPU 也不低但没有任何一个任务真正推进比如两个线程互相让步反复重试或者 CAS 一直失败自旋。活锁比死锁更隐蔽因为它看起来很忙。第三种是线程饥饿。锁被某个长任务一直占着或者线程池被少数几个慢请求全部占满后面的任务排不上队。第四种是阻塞堆积也可以叫资源耗尽型卡死。线程没死也没锁冲突就是卡在某个外部依赖上比如数据库连接拿不到、HTTP 调用没设超时、往一个满队列里塞任务。这种最容易误判因为栈上是清一色的socketRead0或者park。把这四类分清楚之后你会发现一个共同点卡死的本质是某个线程在等一个永远等不到的东西。要么等锁、要么等资源、要么等一个不会返回的调用。所以排查卡死的核心动作就一个——找到所有线程此刻在等什么。这个问题一旦回答清楚八成的问题当场就能定位。1.1 为什么多线程程序特别容易假活单线程程序一旦卡住通常是明确的——要么在跑要么挂了。多线程不一样它是一部分线程死了另一部分线程还在装模作样地活着。心跳线程可能还在每秒报告一次健康状态因为它走的是独立线程、不碰业务锁监控线程还在采集指标因为它只读不写。对外表现就是服务在线但不可用从负载均衡的视角看它是健康的流量照样往里打于是越来越堵。这个特性决定了一件事健康检查不能只检查进程存活一定要检查业务线程池的可用容量。我个人习惯在健康检查里加一项空闲业务线程比例一旦空闲线程低于总容量的 10% 且持续 30 秒就直接把实例拉出集群。这比等到请求超时堆积再报警要早得多很多卡死事故如果早点摘流量根本不会扩散成全局故障。1.2 排查前必须先准备好的三份信息很多人卡死之后第一反应是重启重启确实能恢复但也把现场毁了。我现在的习惯是重启之前必须把现场抓下来而且是有准备地抓。有三份信息是排查的前提缺一个都会让后续分析变得很痛苦。进程 PID 和线程命名规范。给线程起名字这件事看起来是小事但在排查的时候价值巨大。一个叫order-timeout-checker的线程和一个叫pool-3-thread-7的线程在栈里能提供的线索完全不是一个量级。JDK 里用ThreadFactoryBuilder().setNameFormat()C 里用pthread_setname_np()Python 里在threading.Thread(name...)里给上成本极低收益极高。最近一次变更的时间点。卡死往往不是新问题而是被某个变更触发的。线程池参数从有界改成无界、某个接口新增了一次远程调用、锁的范围被顺手扩大了一圈这些都是导火索。把变更记录和故障时间对齐能省掉一大半的猜测。可用的诊断工具。Java 场景要能执行jstack和jcmdC 场景要能 attachgdb或者 preload 一个信号处理Python 场景最好提前装好py-spy。这些工具临时装往往来不及尤其是生产环境权限卡得很死的时候。提示养成在发版时顺手确认诊断工具可用性的习惯比出事之后再申请权限靠谱得多。我见过太多次因为生产环境没装gdb、py-spy装不上最后只能靠猜和重启。2. 第一招线程栈快照定位法遇到卡死我的第一反应永远是抓线程栈而且要连续抓几次。这是四招里最基础也最有效的一招能解决大部分我完全不知道卡在哪的场景。原理很简单线程栈告诉你在这一刻每个线程在执行什么、在等什么锁、持有哪个锁。一次快照能看出静态的等待关系多次快照能看出哪些线程是卡住不动的哪些只是恰好路过。为什么强调连续抓因为单次快照会骗人。一个线程可能正好停在一个正常的方法调用上但如果你隔 5 秒再抓一次发现它还停在同一行、同一个栈帧那基本可以确定它就是卡住的那一个。我一般的做法是抓 3 次间隔 5 到 10 秒然后做差集。三次都出现在同一个位置的线程就是嫌疑最大的。2.1 Java 场景下 jstack 的用法和解读Java 生态里最顺手的就是jstack。命令门槛很低# 抓取线程栈快照-l 会额外输出锁的持有关系 jstack -l pid stack_1.txt # 如果需要更详细的信息可以配合 jcmd jcmd pid Thread.print -l stack_2.txt很多人只知道jstack能打栈不知道-l参数会附带Locked ownable synchronizers和waiting to lock的信息而这才是定位死锁的关键。抓下来之后怎么读我一般按这个顺序看观察点说明常见线索线程状态统计栈文件开头会给出各状态的线程数量大量 BLOCKED 说明锁竞争严重大量 WAITING 说明在等待条件相同栈帧多个线程停在同一个方法大概率是锁竞争或者线程池耗尽锁持有关系谁持有锁、谁在等这把锁形成环就是死锁native 帧socketRead0、futex_wait指向 IO 阻塞或底层锁等待Java 还有一个很好用的命令是jstack -F配合jcmd的Thread.print在jstack因为 safepoint 卡住的时候能救急。另外提一句JDK 自带的jconsole和jvisualvm也有检测死锁按钮但生产环境一般不方便开图形界面命令行还是主力。注意jstack依赖 JVM 到达安全点safepoint。如果某个线程在跑一个巨大的无 safepoint 循环jstack可能会挂住几秒甚至几十秒。这时候用jcmd pid Thread.print会更稳一点实在不行才考虑jstack -F。2.2 C/C 场景用 gdb 批量抓栈C 没有 JVM 那套现成的工具得靠gdb。基本玩法是 attach 上去然后对每个线程打 backtrace# 非交互式抓取所有线程的调用栈 gdb -p pid -batch -ex thread apply all bt gdb_stacks.txt # 如果有调试符号加上 -ex thread apply all bt full 能看到更多局部变量 gdb -p pid -batch -ex set pagination off -ex thread apply all bt full gdb_full.txtthread apply all bt这一句是核心它会把所有线程挨个打印一遍调用栈。C 场景下最常见的卡死信号是pthread_mutex_lock、pthread_cond_wait、futex这几个符号看到大量线程堆在futex_wait上基本就是锁的问题。还有一个非常好用的办法是用 gdb 打印互斥锁的持有者比如pthread_mutex_t结构里能看到__owner字段直接告诉你谁拿着这把锁不放。C 还有个坑要提前说发布版本如果没带调试符号抓出来的栈全是地址等于白抓。所以我的习惯是发布时保留一份带符号的二进制和对应的 core 文件需要的时候用gdb binary core去还原符号。这个投入在排查卡死的时候回报率极高。2.3 Python 场景的 py-spy 与 faulthandlerPython 因为 GIL 的存在卡死问题有它自己的味道。纯 CPU 计算的多线程在 Python 里其实是被 GIL 串行化的真正容易卡死的是 IO 和锁的组合。诊断工具我个人首选py-spy因为它不需要侵入代码、不需要重启直接 attach# 实时抓取所有线程栈 py-spy dump --pid pid # 每秒采样一次持续 10 秒用来观察哪些栈帧反复出现 py-spy top --pid pidpy-spy dump的好处是能把每个线程的 Python 栈和 C 栈都打出来GIL 的持有者也会标出来。另一个零成本方案是在进程里提前埋faulthandlerimport faulthandler # 在启动时注册10 秒后如果还有卡住的情况就把所有线程栈打到文件 faulthandler.dump_traceback_later(10, repeatFalse, fileopen(traceback.log, w))这个方案的价值在于它不需要你手动触发进程一旦卡住超时后自动把现场落到文件里尤其适合那种人还没上机器、服务已经挂了的凌晨故障。实操心得Python 里很多卡死其实是死在socket的默认超时上。requests如果不显式设timeout它默认是无限等待的。我现在的规矩是任何网络调用必须有 timeoutrequests.get(url, timeout(3, 10))这种连接和读取分开设的写法才是标准动作。3. 第二招锁顺序与加锁粒度治理抓完栈定位到锁接下来就是治理。锁引起的卡死绝大多数都能归到两个原因加锁顺序不一致和锁的范围太大。这一招的核心思路是把锁的获取顺序全局统一同时把锁的粒度尽可能缩小。3.1 死锁的四个必要条件怎么破教科书上讲死锁有四个必要条件互斥、持有并等待、不可剥夺、循环等待。这四个条件只要破掉一个死锁就成立不了。实际工程里最容易破的是循环等待也就是统一加锁顺序。为什么选它因为互斥是共享资源的天性改不掉不可剥夺意味着要支持锁的强制释放实现复杂还容易出错持有并等待可以通过tryLock缓解但会引入重试逻辑。相比之下统一锁顺序是纯约定层面的改动成本最低、收益最直接。具体怎么做给所有的锁分配一个全局唯一的序号任何线程在需要多把锁的时候必须按序号从小到大获取。比如锁 A 编号 1、锁 B 编号 2那么所有地方都必须是先拿 A 再拿 B绝不能反过来。这样就不可能出现A 等 B、B 等 A的环。序号可以用枚举、可以用对象 hash甚至可以用字符串排序关键是全局唯一且稳定。3.2 统一锁顺序的落地方法光有约定不行得让约定变成代码里能落地的东西。我通常用两层保障一层是封装加锁方法一层是静态检查。封装的做法是把按序加锁变成一个工具方法业务代码不直接调lock()而是调封装好的lockAll(lockA, lockB)。这样加锁顺序由工具方法统一处理业务方无所谓传参顺序。// 思路示意把多把锁排序后再依次获取 public static void lockAll(ReentrantLock... locks) { // 按锁的全局编号排序保证任何调用点顺序一致 Arrays.sort(locks, Comparator.comparingInt(LockUtil::getId)); for (ReentrantLock lock : locks) { lock.lock(); } } public static void unlockAll(ReentrantLock... locks) { // 解锁顺序无所谓但好的习惯是逆序释放 for (int i locks.length - 1; i 0; i--) { locks[i].unlock(); } }静态检查那层可以用阿里开源的p3c之类的规则插件或者干脆在 code review 清单里加一条涉及多把锁的地方检查是否走封装。我个人的经验是光靠人盯一定会漏尤其是团队人数上来之后必须有工具或者准入门槛兜底。3.3 tryLock 超时给等待加一条退路统一锁顺序解决的是同时要拿多把锁的场景但还有一种情况是单把锁被长期占用导致的饥饿。这种时候tryLock配合超时就是标配。核心逻辑是等待超过阈值就放弃把已经拿到的锁放掉让别的线程有机会推进。// 带超时的加锁拿不到就放弃避免无限等待 if (lock.tryLock(500, TimeUnit.MILLISECONDS)) { try { // 临界区逻辑 } finally { lock.unlock(); } } else { // 拿不到锁走降级逻辑或抛出可重试异常 throw new RetryableException(acquire lock timeout); }这里有个细节很多人忽略tryLock失败之后不要立刻原地自旋重试那会变成活锁。正确做法是退出来交给上层做退避比如 sleep 一个随机时间再试或者干脆走降级路径。另外tryLock拿到锁之后的业务逻辑如果有嵌套加锁一定要保证嵌套的那层也能快速失败不然超时保护等于没有。3.4 锁粒度、读写锁和无锁结构的取舍锁用对了顺序还不够粒度也很关键。我见过最典型的反面案例是有人在synchronized块里做了一次 HTTP 调用。这个锁一旦被远程调用的超时拖住所有等它的线程全废。原则很简单——锁里只做内存操作任何 IO、任何远程调用、任何可能阻塞的动作都必须搬到锁外面。再具体一点读写锁的选择也有讲究。ReentrantReadWriteLock在读多写少的场景确实能提升并发度但它有个隐患写饥饿。如果读请求一直不断写线程可能长时间拿不到锁。JDK 8 之后StampedLock在部分场景表现更好但它的 API 更复杂且不支持重入用错了会死得很惨。我的建议是先评估读写比例如果写操作占比超过 10%老老实实用普通互斥锁别为了那点理论上的并发收益引入复杂度。至于无锁结构ConcurrentHashMap、AtomicLong、LongAdder这些在高并发计数和缓存场景非常成熟能替换掉大量不必要的锁。但要注意无锁不等于没成本CAS 在竞争激烈时会自旋消耗 CPU用之前最好压测一下。提示有一种特别隐蔽的锁——类加载锁和静态初始化锁。两个线程互相触发对方类的静态初始化就可能卡在一起。排查的时候如果栈上出现clinit或者Class.forName要高度警惕。4. 第三招线程池与任务队列的容量设计线程池是卡死的重灾区而且它的卡死往往最安静——线程都老老实实待在池子里既没死锁也没报错就是任务排队排不动了。这一招的核心是让线程池的参数有据可依让队列有界让任务能快速失败。4.1 线程池耗尽的隐蔽链路先说一个我印象很深的案例因为它完整展示了卡死不一定是锁的问题。一个订单服务所有接口共用一个线程池某天开始偶尔超时。查栈发现大量线程堆在调用第三方支付接口上。原因是一个新上线的功能在业务线程里同步调用了一个响应很慢的外部接口没设超时这批请求把线程池全部占满其他接口的请求只能排队。表现就是明明不相关的查询接口也开始超时。这条链路的隐蔽之处在于调用方看不出任何异常它只是慢慢到超时。线程池本身没有任何错误日志队列满了才会打印拒绝而队列如果设置得很大比如无界队列连拒绝都不会发生只会无限堆积然后 OOM。所以第一个结论是队列必须有界。4.2 线程池参数怎么算才靠谱线程池的核心参数里最容易拍脑袋的就是核心线程数和最大线程数。业界有个经验公式虽然不是绝对准确但作为起点很好用CPU 密集型任务核心线程数 CPU 核数 1。加 1 是为了在某个线程偶尔缺页或者被调度打断时CPU 不至于空闲。IO 密集型任务核心线程数 CPU 核数 × 2或者更激进一点用 CPU 核数 / (1 - 阻塞系数) 来算。阻塞系数是任务中阻塞时间占总时间的比例比如一次任务里 90% 时间在等 IO那线程数可以开到核数的 10 倍左右。任务类型核心线程数参考队列策略拒绝策略建议CPU 密集核数 1有界小队列AbortPolicy快速失败IO 密集核数 × 2 起按阻塞系数上探有界中等队列AbortPolicy 或 CallerRuns混合型拆成两个池分别配置各自有界分开的拒绝策略这里要特别提醒一个坑CallerRunsPolicy会阻塞调用方线程。它在很多场景下确实能起到背压的作用但如果调用方是 Tomcat 的工作线程或者 Dubbo 的业务线程这个策略会让调用方线程被任务占住反而加剧卡死。我一般只在后台批处理任务里用它Web 请求链路上优先用AbortPolicy配合降级。4.3 父任务等子任务那个经典的线程池死锁这是线程池卡死里最经典的一种也是面试的高频题。场景是一个任务被提交到线程池它在执行过程中又提交了子任务到同一个线程池然后阻塞等待子任务的结果。如果线程池里所有线程都在跑父任务、都在等子任务而子任务因为没有空闲线程永远排不上队整个池子就锁死了。解决办法有几个优先级从高到低不要用同一个线程池。父任务和子任务用隔离的两个池父任务池的线程不会被自己的子任务阻塞。用ForkJoinPool。它的工作窃取机制本质上能让等待子任务的线程去干活天然规避这个问题。拆解任务直接把子任务逻辑内联。如果子任务本来就是父任务的一部分、没有并发必要直接同步执行最省事。我个人的偏好是方案一因为最直白、最容易在代码里看出来。方案二虽然优雅但ForkJoinPool自己的坑也不少比如阻塞时对线程数的估算团队不熟的话不如隔离池稳。4.4 隔离与降级别让一个慢依赖拖垮全部线程池治理的最后一步是按业务隔离。把所有任务塞进一个大池子是最省事也最危险的做法。我的标准动作是核心接口一个池、非核心接口一个池、异步通知一个池、定时任务一个池。池与池之间不共享线程某个池被打满不会波及别人。隔离之外还要配降级。降级不是等出事了再想而是提前设好接口失败率超过阈值自动降级、线程池队列占用超过 80% 触发限流、慢调用比例超标触发熔断。这些机制在手写代码里能实现用成熟框架比如 Sentinel、Resilience4j 也行。关键不是工具而是有没有在关键链路上埋这些开关。实操心得给线程池起名字这件事在线程池场景下比单线程更重要。new ThreadPoolExecutor(...)一定要传一个自定义的ThreadFactory把池名和业务名编进去比如order-pay-pool-1。出问题抓栈的时候你一眼就能看出是哪个池、哪个业务卡住了。5. 第四招资源等待与阻塞点治理前三招处理的是锁、线程池和栈定位这最后一招处理的是最容易被忽略、但也最普遍的一类——阻塞在外部资源上。这类卡死的特征是没有锁竞争、线程池参数也合理但线程就是卡在某个系统调用上回不来。5.1 超时全覆盖任何可能阻塞的操作都要有超时这一点说起来简单做起来最容易漏。要覆盖的地方包括网络调用HTTP 客户端的连接超时和读取超时Socket 的SO_TIMEOUTRPC 框架的超时配置。这种一定要坐实HttpClient的connectTimeout和responseTimeout分开设只设一个等于没设。数据库连接池的获取连接超时、语句执行超时、事务超时、锁等待超时。以 HikariCP 为例connectionTimeout默认 30 秒validationTimeout默认 5 秒这些都要根据业务实际情况调别用默认值。锁前面说的tryLock超时。队列操作BlockingQueue.take()和put()都是无限的用offer()和poll()带超时的版本替代。CountDownLatch.await()和CyclicBarrier.await()这两个都提供了带超时的重载务必用带超时的那个。这里我特别想强调Java 里future.get()不带超时这个坑。它会让调用线程一直等下去而且不会响应中断之外的任何信号。正确的写法是future.get(3, TimeUnit.SECONDS)超时了抛TimeoutException走降级。5.2 连接池与外部依赖的治理数据库连接池和 HTTP 连接池是两大卡死源头因为它们都有有限资源 无限等待的组合。连接池的核心参数有四个最大连接数、最小空闲连接、获取连接超时、连接最大存活时间。最大连接数不是越大越好——数据库本身的连接数是有上限的业务侧连接池加起来超过数据库上限反而会互相挤兑。一个常见的误判是连接池不够用的时候很多人第一反应是加大最大连接数。但如果瓶颈在数据库端比如慢查询占用连接不释放加大连接数只会让数据库更慢最后雪崩。正确的做法是先看连接被谁占着、占多久定位到慢查询再优化最后才谈扩容。HTTP 连接池也是同理。maxConnections、maxConnectionsPerHost、connectionRequestTimeout这几个参数要成套配置。尤其是在微服务调用链里一个服务调用超时会在链路上放大上游的连接池被拖垮然后继续往上传。5.3 那些不起眼但会咬人的阻塞点除了网络和数据库还有几个隐蔽的阻塞点值得单独提日志同步锁。同步写日志在高并发下会成为瓶颈尤其是磁盘慢的时候。用AsyncAppender能缓解但要注意它的队列满了之后的行为——默认是丢弃还是阻塞得看清楚。synchronized触发的偏向锁撤销。这个属于 JVM 层面的细节正常情况下不会导致卡死但在极端竞争下synchronized的膨胀过程会有开销。JDK 15 之后偏向锁已经默认禁用这个坑新一代的开发者基本遇不到了。System.gc()引起的全停顿。有人在代码里手动调System.gc()在高并发下会引发一次次长停顿看起来像卡死。这种问题抓栈是抓不到的得看 GC 日志。文件锁。多进程或者多线程同时读写同一个文件如果没处理好文件锁也会卡住。这种在嵌入式或者数据处理场景更常见。注意查不到锁、查不到线程池问题的时候一定要去看 GC 日志和系统层面的iostat、vmstat。卡死的原因可能根本不在你的代码里而在系统资源被耗光上。5.4 监控埋点把卡死掐死在萌芽所有治理手段里最省心的其实是提前发现。等用户投诉再来查损失已经造成了。我现在的标配是三类监控线程池指标活跃线程数、队列长度、已完成任务数、拒绝次数。后台把这些指标打点到监控系统设置合理的告警阈值。锁指标可以用 JMX 的ThreadMXBean.findDeadlockedThreads()定期检测死锁也可以用 Micrometer 之类的库采集锁等待时间。检测到死锁直接告警加 dump 现场。慢调用指标每个外部调用的 P99 延迟一旦超过阈值就告警。卡死往往是慢调用累积的结果慢调用了就能提前预警。// 定期检测死锁并 dump 现场这个定时任务本身要用独立线程 ThreadMXBean mxBean ManagementFactory.getThreadMXBean(); long[] deadlocked mxBean.findDeadlockedThreads(); if (deadlocked ! null deadlocked.length 0) { ThreadInfo[] infos mxBean.getThreadInfo(deadlocked, true, true); // 这里做告警 落盘方便事后分析 }findDeadlockedThreads只覆盖经典死锁检测不到线程池耗尽和资源阻塞所以它只是监控的一部分不能只靠它。6. 常见问题速查与避坑清单前面四招讲的是方法和原理最后这部分我想把排查过程中最常遇到的问题整理成一张速查表方便现场对号入座。这些都是我自己遇到过或者帮同事排查过的真实场景比泛泛的理论更有指向性。6.1 卡死问题速查表现象可能的根因快速验证方式处理方向多个线程状态为 BLOCKED栈上互相等锁死锁或锁竞争jstack -l看锁环findDeadlockedThreads统一锁顺序缩小锁粒度线程全在socketRead0/futex_wait外部依赖阻塞无超时看调用栈的类名确认调用目标加超时调用移出锁线程池活跃数打满队列持续增长慢任务占满线程看线程池指标和任务栈隔离线程池队列设界降级CPU 高但任务不推进活锁或 CAS 自旋看火焰图定位自旋点退避重试限制自旋进程停顿、栈抓不出来GC 长停顿或 safepoint看 GC 日志排查内存泄漏调 GC 参数Python 进程卡住无响应GIL 被占或 socket 阻塞py-spy dump换多进程加 timeout父任务等子任务永远不返回同一线程池嵌套提交看栈上有无同类submit帧拆分线程池或用 ForkJoinPool这张表不能覆盖全部情况但它覆盖了日常遇到的 80%。真正现场排查的时候我的顺序是先看状态统计、再看相同栈帧、最后看锁和资源这个顺序能让大部分问题在十分钟内有个方向。6.2 几个容易踩的坑最后说几个我觉得最值得记下来的经验点。第一别急着重启。卡死现场是最宝贵的信息重启之后就没了。养成先 dump 后重启的肌肉记忆哪怕只是抓一份jstack也比什么都没有强。第二卡死往往是阈值问题而不是逻辑错误。很多多线程程序在低并发下完全正常一到高并发就卡逻辑上没毛病就是参数设计得太紧。线程池小、超时长、队列大随便一个都可能在压力下变成卡死。压测一定要在接近生产流量的规模下做小流量的压测看不出这些问题。第三卡死和性能问题经常是一回事的两面。一个请求从 50ms 变成 5s看起来是性能问题但它可能持续占着线程和锁最后演变成卡死。所以慢调用治理和卡死治理本质上是一套功夫监控指标也应该统一起来看。第四写并发代码的时候,多问自己一句这个等待有没有上限。每一个wait、get、await、take、read都要能回答如果它永远不返回我会怎么样。回答不上来的地方就是将来的事故点。我在实际使用中的体会是多线程卡死从来不是某一个灵丹妙药能一次性解决的它考验的是整个链路上每一个等待点的设计是否合理。你把这篇文章里的四招吃透——栈定位、锁治理、线程池容量、阻塞点治理——再加上平时的监控埋点和压测习惯大部分卡死问题都能在它造成大范围影响之前被拿下最少也能在故障发生时快速定位到根因。真正难的不是修而是知道去哪里看、看什么。
