状态检测接口出现偶发的线程阻塞问题

[cyl520134]

你的特性请求和某个问题有关吗？请描述

容器化部署，部署了36pod，每个pod的tomcat的线程数最大是80，生产上偶发线程阻塞突升，从异常日志堆栈中看

异常主要发生在代码：

清晰简洁地描述一下你希望的解决方案

由于使用的是Multimaps.synchronizedSetMultimap定义的deferredResults，其内部的put和remove方法都使用了synchronized锁，所以每次for循环均会有加解锁的操作，底层代码如下：

清晰简洁地描述一下这个特性的备选方案

Multimaps.synchronizedSetMultimap同步锁粒度是否可以更小，比如使用重构在for循环外部加synchronized同步块，或者使用ConcurrentHashMap使锁粒度更小，会不会产生新的问题

其它背景

在这里添加和这个特性请求有关的背景说明、截图

清晰简洁地描述一下你希望的解决方案

清晰简洁地描述一下这个特性的备选方案

其它背景

在这里添加和这个特性请求有关的背景说明、截图

[dosubot]

Hi @cyl520134! I'm Dosu and I’m helping the apollo team.

你遇到的线程阻塞问题，根本原因是 deferredResults 使用了 Guava 的 Multimaps.synchronizedSetMultimap，这会导致所有 put/remove/get 操作都竞争同一个锁，在高并发场景下容易出现线程阻塞和性能瓶颈。每次 for 循环移除 DeferredResultWrapper 时，都会反复加解锁，进一步加剧了锁竞争 相关源码分析。

将 synchronized 块移到 for 循环外部并不能改善问题，反而会让锁持有时间变长，导致更多线程等待，整体吞吐量下降。

如果用 ConcurrentHashMap + 线程安全的 Set（如 CopyOnWriteArraySet 或 Collections.newSetFromMap(new ConcurrentHashMap)），可以把锁粒度降到 key 级别，减少全局锁竞争。但需要注意：多线程下复合操作（比如 get-then-remove）要保证原子性，否则可能出现遗漏通知或重复通知的问题。迁移时建议重点测试高并发下的正确性和 race condition。

目前 Apollo 没有官方文档说明为什么用 synchronizedSetMultimap，主要是为了简单线程安全，但在高并发场景下确实不够理想。如果你考虑重构，建议先在测试环境模拟高并发场景，重点关注通知丢失、重复和性能指标，确保新方案能兼容原有业务逻辑。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[cyl520134]

第一种将 synchronized 块移到 for 循环外部持有锁时间变长，但会减少频繁的加减锁操作，测试环境下实测线程阻塞发生的概率会降低

[dosubot]

你的测试结论是有道理的：把 synchronized 块放到 for 循环外，确实会减少频繁的加解锁操作，降低锁竞争，线程阻塞概率在部分场景下会下降。这种做法的核心权衡在于：锁持有时间变长，期间其它线程无法对 deferredResults 做 put/get/remove 操作，但整体锁竞争次数减少，适合批量操作较多、单次操作很快的场景。

Apollo 现有实现用的是 Guava 的 synchronizedSetMultimap，所有操作都串行化在一个全局锁上，for 循环每次 remove 都会加解锁一次，导致高并发下容易出现阻塞源码参考。目前代码和历史 PR 里没有对锁粒度或锁范围的详细讨论，也没有相关的官方 benchmark。

如果 for 循环内部操作本身很快（比如只是简单的 remove），把锁放到外面通常不会带来明显的副作用。但如果后续有慢操作（比如网络、IO），则要小心锁被长时间占用，影响其它请求。

总之，这种优化建议在你的业务场景和压力下充分测试，关注高并发下的吞吐、延迟和正确性。如果后续考虑更细粒度的并发结构（如 ConcurrentHashMap + 线程安全 Set），还需注意复合操作的原子性和一致性。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[nobodyiam]

可以考虑使用 ConcurrentHashMap 实现 Multimap 的语义来降低锁的颗粒度

[nobodyiam]

@cyl520134 Copilot 基于 ConcurrentHashMap 实现了一个版本，可以看下是否能解决你描述的问题 #5451