当前位置： 首页 > news >正文

ConcurrentHashMap导致的死锁事故

news 2025/5/22 10:45:35

事故现象

某线上服务共100台容器，第二天上午流量高峰期部分容器（约10%）cpu飙升，升至100%。

部分堆栈信息

堆栈信息如下如所示：

当前线程堆栈显示在JsonContext.get方法中调用computeIfAbsent，其Lambda表达式（JsonContext$$Lambda$1329）内部触发了Program.process和Script.eval，最终再次调用JsonContext.get，形成递归。

直接原因：Java 8的ConcurrentHashMap.computeIfAbsent在计算函数中重入同一键会导致死锁，因为内部锁不可重入

可以看到当前线程虽然是RUNNABLE 状态，但当前线程自身因递归调用导致锁无法释放，属于自死锁，无其他线程介入。

原因分析

ConcurrentHashMap 的锁机制

  • computeIfAbsent 在计算过程中会对当前键的哈希桶（bin）加锁（使用 synchronized 或 CAS 操作）。

  • 当计算函数内部再次尝试操作同一键时：

    • 外层操作已持有该键的锁。

    • 内层操作尝试获取同一锁 → 锁重入被禁止 → 线程阻塞。

与 HashMap 的区别

  • 普通 HashMap 允许重入，但可能引发无限递归（导致 StackOverflowError）。

  • ConcurrentHashMap 为保障线程安全，禁止这种重入行为。

在 ConcurrentHashMap 的源码中，computeIfAbsent 的关键逻辑如下：

if (bin != null) {synchronized (bin) {  // 对哈希桶加锁if (mappingFunction.apply(key) != null) {// 计算过程中再次尝试操作同一键会导致死锁}}
}

  • 锁粒度：以哈希桶（链表或红黑树节点）为单位加锁。

  • 重入限制：同一线程无法重复获取同一锁。

流量因素

由于触发重入锁的请求量较少，少于容器数量，且均在前一天晚上，流量处于低峰期，当时并没有关注cpu波动。流量高峰期时，卡住的容器请求数量增多，导致cpu飙升。此时分析堆栈文件已经有270+线程处于TIME_WAITING状态。

 

"JSF-BZ-22001-29-T-60" #11213 daemon prio=5 os_prio=0 tid=0x00007f0e10012000 nid=0x25e35 runnable [0x00007f07a6d11000]java.lang.Thread.State: TIMED_WAITING (parking)at sun.misc.Unsafe.park(Native Method)at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)at com.lmax.disruptor.MultiProducerSequencer.next(MultiProducerSequencer.java:136)at com.lmax.disruptor.MultiProducerSequencer.next(MultiProducerSequencer.java:105)at com.lmax.disruptor.RingBuffer.next(RingBuffer.java:263)at com.engine.disruptor.publisher.ObservedPublisher.publish(ObservedPublisher.java:20)at com.engine.RuleEngine.processRule(RuleEngine.java:81)at com.engine.RuleEngine.processRules(RuleEngine.java:67)at com.engine.RuleEngine.eval(RuleEngine.java:55)at com.engine.RuleEngine$eval.call(Unknown Source)at com.api.strategy.pre.BeforePDPStrategy.eval(script17477914260641953553839.groovy:108)at sun.reflect.GeneratedMethodAccessor3436.invoke(Unknown Source)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:498)at org.codehaus.groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43)at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:190)at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:58)at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:168)at com.api.strategy.pre.BeforePDPStrategy.execReq(script17477914260641953553839.groovy:37)at com.rule.engine.GroovyRuleEngine.exec(GroovyRuleEngine.java:27)at com.service.core.strategy.PreStrategyExecutor.handle(PreStrategyExecutor.java:112)at com.service.core.baseCore.FilterService.filter(FilterService.java:66)at com.api.PdpSecurityFilterService.filter(PdpSecurityFilterService.java:46)at sun.reflect.GeneratedMethodAccessor2550.invoke(Unknown Source)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:498)at com.gd.filter.ProviderInvokeFilter.reflectInvoke(ProviderInvokeFilter.java:160)at com.gd.filter.ProviderInvokeFilter.invoke(ProviderInvokeFilter.java:104)at com.gd.filter.ProviderSecurityFilter.invoke(ProviderSecurityFilter.java:42)at com.gd.filter.ProviderConcurrentsFilter.invoke(ProviderConcurrentsFilter.java:61)at com.gd.filter.ProviderTimeoutFilter.invoke(ProviderTimeoutFilter.java:37)at com.gd.filter.ProviderMethodCheckFilter.invoke(ProviderMethodCheckFilter.java:78)at com.gd.filter.ProviderInvokeLimitFilter.invoke(ProviderInvokeLimitFilter.java:57)at com.gd.filter.ProviderHttpGWFilter.invoke(ProviderHttpGWFilter.java:29)at com.gd.filter.ProviderUnitValidationFilter.invoke(ProviderUnitValidationFilter.java:30)at com.gd.filter.ProviderGenericFilter.invoke(ProviderGenericFilter.java:77)at com.gd.filter.ProviderContextFilter.invoke(ProviderContextFilter.java:54)at com.gd.filter.ProviderExceptionFilter.invoke(ProviderExceptionFilter.java:30)at com.gd.filter.SystemTimeCheckFilter.invoke(SystemTimeCheckFilter.java:79)at com.gd.filter.FilterChain.invoke(FilterChain.java:294)at com.gd.server.ProviderProxyInvoker.invoke(ProviderProxyInvoker.java:59)at com.gd.server.JSFTask.doRun(JSFTask.java:108)at com.gd.server.BaseTask.run(BaseTask.java:104)at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)at java.util.concurrent.FutureTask.run(FutureTask.java:266)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)at java.lang.Thread.run(Thread.java:748)Locked ownable synchronizers:- <0x0000000714be3208> (a java.util.concurrent.ThreadPoolExecutor$Worker)

可以看到线程正在调用RingBuffer.next()时，因Disruptor 环形缓冲区（RingBuffer）已满，无法立即获取下一个可用的序列号（Sequence），导致线程进入短暂的等待状态（通过LockSupport.parkNanos()实现）。

Disruptor 的工作机制：

  • Disruptor 是一个高性能的无锁环形队列，用于生产者和消费者之间的数据交换。
  • 生产者调用RingBuffer.next()获取下一个可写入的序列号。
  • 如果缓冲区已满（生产者速度超过消费者），生产者需要等待直到有空间可用。

代码路径：

  • MultiProducerSequencer.next()的实现会检查缓冲区是否有可用空间。
  • 如果无可用空间，会调用LockSupport.parkNanos(nanos)，让线程进入TIMED_WAITING状态，等待一段时间后重试（避免忙等）

TIMED_WAITING 的含义：

  • 线程没有阻塞在 I/O 或同步锁上，而是通过parkNanos()主动挂起，等待条件（缓冲区空间）满足。
  • 这是一种性能优化机制，避免线程因自旋（spin-wait）浪费 CPU 资源。

这里其实是线程数增加的原因。因为obs-rule-worker- - 1是disruptor的一个消费线程，它一直自死锁，无法处理当前任务，导致RingBuffer 逻辑上已满，生产者无法申请新写入位置，生产者线程JSF-BZ-22001-29-T-XX，在RingBuffer.next()时通过LockSupport.parkNanos() 进入TIMED_WAITING 状态，接收到新的请求发现线程不够用，又新建了线程，这也就是第一个现象 线程数突增的原因。新增的线程在RingBuffer.next()时也会通过LockSupport.parkNanos() 进入TIMED_WAITING，这也就是JSF监控看到活跃线程突增后下降(下降原因：TIMED_WAITING状态的线程超时时间到期会销毁)，但服务总线程数上升后保持不变的原因。

http://www.xdnf.cn/news/576181.html

相关文章：

  • 环境搭建
  • 根据Spring官方文档，三分钟完成Springboot项目集成Spring AI
  • sqli-labs第十七关——POST注入点
  • Spring Boot整合Redis
  • RestTemplate 发送的字段第二个大写字母变成小写的问题探究
  • 9-码蹄集600题基础python篇
  • leetcode 螺旋矩阵 java
  • 5-码蹄集600题基础python篇
  • 如何设计智慧工地系统的数据库？
  • 系统程序变更管理：确保IT环境稳定性和安全性的关键
  • Entity-Relationship Model（实体-关系模型）
  • FlashAttention：传统自注意力（ Self-Attention）优化加速实现
  • 用户刷题记录日历——签到表功能实现
  • 基于 Guns v5.1 框架的分页教程
  • SseEmitter是什么
  • 卷积神经网络基础（十）
  • chrono类 根据duration 类的周期类型得到对应的周期名称
  • 预警功能深度测评：如何用系统降低设备突发故障率？
  • JavaScript常用事件
  • 第P10周：Pytorch实现车牌识别
  • 如何解决测试覆盖率与迭代速度的冲突问题？
  • 手搓四人麻将程序
  • 正大模型视角下的高频交易因子构建策略研究
  • 视频监控管理平台EasyCVR工业与公共安全监控：监控中心与防爆系统如何集成？
  • 【免杀】C2免杀技术（八）APC注入
  • 数字化转型到底是什么？如何更好的理解数字化转型
  • NOSQL之Redis群集部署
  • 基于Browser Use + Playwright 实现AI Agent操作Web UI自动化
  • 运行时runtime是什么？（程序在运行过程中所依赖的环境、资源管理机制以及动态行为的总和）（包括内存分配、异常处理、线程调度、类型检查、资源访问等）
  • ip地址冲突说明什么问题？ip地址冲突影响网速吗