Collections.synchronizedMap适用于读多写少、初始化后基本只读的场景，如静态配置或字典表；需手动同步复合操作和迭代遍历；不适合高并发写入或需原子复合操作的场景。
Collections.synchronizedMap 是一种轻量级、易上手的线程安全封装方式，适合在读多写少、并发压力不高的场景中快速落地。它不追求极致性能，而重在简洁可控——用对地方，就能省去手动加锁的繁琐；用错场景，反而会成为瓶颈。
适用场景：读多写少 + 初始化后基本只读
当 Map 承担的是静态配置、字典表、国家代码映射、HTTP 状态码说明等角色时，synchronizedMap 很合适：
- 写操作集中在应用启动阶段（如一次性的 loadConfig()），后续几乎全是 get 调用
- get 操作虽被同步，但因无竞争，实际开销极小
- 相比 ConcurrentHashMap，无需理解 computeIfAbsent 或分段锁语义，代码更直白
必须手动同步的两类关键操作
它只保证单个方法（如 put、get、remove）的原子性，以下情况需显式加锁：
- 复合逻辑：比如“若 key 不存在则 put”，不能拆成 containsKey + put 两步，必须包在 synchronized 块里
- 迭代遍历：entrySet()、keySet()、values() 返回的视图不自动同步，遍历时要整体加锁，否则可能抛 ConcurrentModificationException
与 synchronizedList/synchronizedSet 统一风格使用
在遗留系统或团队已有约定中，若 List 和 Set 都用了 Collections.synchronizedXXX，Map 也选用 synchronizedMap 有明显优势：
立即学习“Java免费学习笔记（深入）”；
- 所有集合共享同一套同步模型，调试路径一致，排查问题更直观
- 避免混用 ConcurrentHashMap（弱一致性迭代器）和 synchronizedMap（强一致性但 fail-fast）带来的行为差异
- 单元测试中快速构造线程安全的测试数据容器，无需引入额外依赖
明确不适合的典型场景
一旦出现以下任一情况，就该果断换用 ConcurrentHashMap：
- put/remove 频率高，尤其多线程频繁写入
- 需要边遍历边更新（如定时清理过期项），synchronizedMap 的迭代器会直接失败
- 要求原子性复合操作（如 computeIfAbsent、merge），synchronizedMap 不提供，需自行封装并加锁
