全链路压测中并发容器选用不当引发锁重负载，需提前关注“容器行为+线程竞争+指标异常”交叉信号；表现为高线程、低吞吐、中等CPU、长尾RT，本质是锁争抢导致串行化。
全链路压测中识别并发容器选用不当引发的锁重负载，关键不是等压测崩了再查，而是提前聚焦“容器行为 + 线程竞争 + 指标异常”三者的交叉信号。这类问题往往不报错、不抛异常，但会让系统吞吐骤降、响应时间长尾严重、CPU利用率与QPS/TPS不成正比——本质是锁争抢把线程卡在串行路径上。
看线程堆栈是否扎堆在容器内部方法
压测过程中抓取多次 jstack -l 快照（建议间隔10秒连续抓3–5次），重点搜索以下关键词：
-
ConcurrentHashMap.put、ConcurrentHashMap.get后紧跟synchronized或Unsafe.park -
CopyOnWriteArrayList.add或.set出现在高频写场景（尤其在循环内反复调用） -
LinkedBlockingQueue.offer/poll卡在ReentrantLock.lock()或AbstractQueuedSynchronizer.acquire
若发现多个线程长时间停留在同一容器方法的锁入口（如都 waiting to lock <0x...> 且锁地址一致），说明该容器已成为热点锁点。
对比吞吐与线程活跃度的反常关系
全链路压测中观察核心指标组合：
- TPS 上不去，但线程池活跃线程数持续拉满（如 200/200）
- CPU 使用率中等偏低（40%–60%），远低于预期（正常高并发应接近80%+）
- p99 RT 显著升高，且波动剧烈（例如从 300ms 跳到 2s+），而平均 RT 变化不明显
这种“高线程、低吞吐、中等CPU、长尾严重”的组合，大概率指向同步瓶颈——不是业务逻辑慢，是容器内部锁在排队。
验证容器是否匹配实际读写比例
不同并发容器适用场景差异极大，选错就会放大锁开销：
- 高读低写（如配置缓存）→ 应用
ConcurrentHashMap或Caffeine；若误用Collections.synchronizedMap，每次 get 都要进锁，吞吐直接腰斩 - 低读高写（如实时统计计数器）→ 应用
LongAdder或Striped64子类；若用AtomicLong在极端高并发下会出现 CAS 失败风暴，表现为大量自旋和上下文切换 - 迭代频繁 + 写少 →
CopyOnWriteArrayList合理；但若在压测中每秒新增数百元素，每次 add 都触发数组复制，GC 压力飙升、RT 毛刺频发
用 jcstress 快速验证容器原子性边界
对疑似容器做微基准验证（脱离业务逻辑，只测容器本身）：
- 写一个极简测试类，仅含共享容器 + 多线程 put/get 操作
- 标注
@JCStressTest(mode = Mode.Termination)，用@Actor方法模拟并发访问 - 运行后看结果分布：若出现大量
State.ABORTED或非预期状态（如 size 不等于预期总数），说明容器在当前并发模式下无法保证一致性或性能退化
不复杂但容易忽略。
