Collections.synchronizedMap仅保证单个方法原子性，无法解决复合操作竞态条件；遍历时必须手动同步，否则抛ConcurrentModificationException；相比ConcurrentHashMap，其全表锁性能差且不支持高并发。
为什么 Collections.synchronizedMap 不能直接解决并发修改问题
它只是给每个方法加了 synchronized，但不保证复合操作原子性。比如先 containsKey 再 put，两步之间仍可能被其他线程插队——这叫“竞态条件”，不是加个锁就自动消失的。
常见错误现象：ConcurrentModificationException 依然出现；多线程反复执行 map.get(k) == null ? map.put(k, v) : map.get(k) 返回 null 或旧值；遍历时抛出异常。
- 使用场景：仅适用于单个操作（如独立的
get、put）且调用方能确保无复合逻辑 - 性能影响：所有方法串行化，高并发下吞吐量明显低于
ConcurrentHashMap - 兼容性：JDK 1.2 起就有，无版本风险，但 JDK 5+ 后基本不推荐用于新代码
Collections.synchronizedMap 包装后遍历必须手动同步
文档里那句 “must manually synchronize on the returned map when iterating” 不是提醒，是硬性要求。否则哪怕用了它，for-each 或 iterator() 仍会因结构变更抛 ConcurrentModificationException。
示例错误写法：
Map<String, Integer> syncMap = Collections.synchronizedMap(new HashMap<>());<br>for (String key : syncMap.keySet()) { ... } // ❌ 可能崩溃
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：用
synchronized(syncMap)包住整个遍历块 - 注意：锁对象必须是返回的包装实例，不是原始
HashMap - 如果遍历中还要修改（如
remove），同样得在同步块内做，且不能用Iterator.remove()以外的方式删元素
和 ConcurrentHashMap 的关键区别在哪
根本不在“是否线程安全”，而在“怎么安全”。synchronizedMap 是粗粒度全表锁，ConcurrentHashMap 是分段锁（JDK 7）或 CAS + synchronized（JDK 8+），支持更高并发读写。
- 读操作：后者完全无锁，前者每次
get都要抢锁 - 迭代器：后者返回弱一致性视图，不抛
ConcurrentModificationException；前者必须手动同步才能安全遍历 - 默认行为差异：
ConcurrentHashMap不允许nullkey/value；synchronizedMap继承原 Map 行为（如HashMap允许一个nullkey） - 如果已有代码强依赖
null键值，又想升级并发能力，不能直接换，得先清理数据或改逻辑
什么情况下还能用 Collections.synchronizedMap
只有两个现实条件同时满足时才考虑：一是并发强度低（比如后台定时任务间歇更新配置，QPS < 10），二是必须保留底层 Map 类型的特定行为（如 TreeMap 的有序遍历 + 线程安全封装）。
- 别为了“看起来线程安全”而用——它掩盖问题比解决问题多
- 如果底层是
LinkedHashMap，要注意accessOrder=true时get也会修改结构，此时synchronizedMap的锁能保序，但ConcurrentHashMap不支持这种语义 - 测试时别只测单线程逻辑，至少模拟两个线程交替调用
put和keySet().iterator()，不然压根发现不了遍历崩溃
真正麻烦的从来不是加锁，而是锁的边界和复合操作的隐含依赖。用 synchronizedMap 就得自己画清楚每行代码在哪个锁里、哪些变量状态会被其他线程突变——这点容易被忽略，也最难补救。
