collections.synchronizedmap因方法级同步导致锁粒度太粗，高并发下性能急剧下降；其每个public方法均用synchronized(this)加全局锁，使读写操作无法并行，遍历期间全表独占，引发线程阻塞与延迟飙升。
直接用 Collections.synchronizedMap 包装 HashMap，看似解决了线程安全问题，但它的“方法级同步”本质会成为高并发场景下的性能放大器——不是锁没起作用，而是锁得太宽、太重、太频繁。
理解 synchronizedMap 的锁粒度陷阱
它对 每一个 public 方法（put、get、remove、size、entrySet 等）都加了 synchronized(this)。这意味着：
- 哪怕只是读一个 key，也要竞争同一把全局对象锁
- 一次
entrySet().iterator()遍历，整个 Map 在遍历期间被独占，其他线程全部阻塞 - 多个无关的写操作（如不同 key 的 put）无法并行，串行化执行
- 锁竞争在高 QPS 下会迅速体现为线程阻塞、CPU 空转、响应延迟飙升
定位瓶颈的三类典型线索
别只看 CPU 或 GC，重点抓锁行为本身：
-
线程堆栈中大量 WAITING / BLOCKED 状态：jstack 抓取时，若看到数十上百个线程卡在
java.util.Collections$SynchronizedMap.get或.put的monitorenter，基本可断定是这把锁卡住了 - 监控指标出现“锯齿状”延迟毛刺：TP99 延迟随并发数非线性跳升，且每次毛刺都对应一批请求超时，大概率是锁争抢导致的排队雪崩
- size()、keySet()、values() 调用量异常高：这些方法同样被同步，如果业务频繁调用（比如日志打点、健康检查轮询），会无谓加剧锁竞争
验证与隔离的实操步骤
不靠猜，靠可测量的对比：
- 用 JFR（Java Flight Recorder）开启锁事件采样，重点关注
jdk.JavaMonitorEnter事件的平均等待时间与总阻塞次数，筛选出耗时最长的 synchronizedMap 实例 - 临时将该 Map 替换为
ConcurrentHashMap，保持其余逻辑不变，压测对比吞吐量与 P99 延迟——若提升显著（常见 3–8 倍），说明原瓶颈确实在 synchronizedMap - 检查是否误用：确认没有在 synchronizedMap 上再套一层
synchronized(map) { ... }，这种双重加锁会让问题恶化数倍
替代方案选型建议
不是所有场景都适合一刀切换 ConcurrentHashMap：
- 纯读多写少（读占比 >95%）、且需强一致性遍历：可保留 synchronizedMap，但必须将遍历逻辑移到同步块外，改用
map.keySet().toArray()先取 key 快照，再逐个 get - 读写混合、强调吞吐：直接切到
ConcurrentHashMap，JDK 8+ 的 CAS + synchronized 桶级锁能支撑千级并发写入 - 需要阻塞式操作（如 putIfAbsent + wait for result）：考虑
ReentrantLock手动控制更细粒度的临界区，或引入BlockingQueue解耦
本质上，synchronizedMap 是一把“全屋大门锁”，而生产环境真正需要的是“每间房独立门锁 + 公共走廊无锁通行”。看清锁的覆盖范围，比急着加锁更重要。
