ConcurrentHashMap 比 Hashtable 更常用，因其采用分段锁（JDK 7）或 CAS + synchronized（JDK 8+）实现桶级锁定，避免全表锁瓶颈；但 size() 非原子、不支持 null、computeXXX 方法需防死锁与阻塞。
ConcurrentHashMap 为什么比 Hashtable 更常用
因为 ConcurrentHashMap 在保证线程安全的同时，避免了 Hashtable 全表锁的性能瓶颈。它采用分段锁（JDK 7）或 CAS + synchronized（JDK 8+）策略，只锁定桶（bin）级节点，允许多个线程并发读写不同段。
常见误用：把 ConcurrentHashMap 当作“完全无锁”容器——实际在扩容、computeIfAbsent 或迭代过程中仍可能阻塞部分线程。
-
put和get基本是无锁的（JDK 8+），但size()不是原子操作，返回的是估算值；如需精确计数，改用mappingCount() - 不支持
null作为 key 或 value，否则抛NullPointerException；而HashMap允许一个nullkey - 迭代器弱一致性：遍历时允许其他线程修改，不会抛
ConcurrentModificationException，但可能漏掉刚插入的元素，也不会反映删除后的状态
什么时候该用 Collections.synchronizedMap
仅当已有 HashMap 实例且改造成本低、并发度不高（如配置缓存、单写多读场景）、又不想引入新依赖时才考虑。它本质是对所有 public 方法加同一把 mutex 锁，等价于手动同步整个 map 实例。
典型陷阱：以为包装后就“线程安全”，却在外部做复合操作（如先 containsKey 再 put）——这仍是竞态条件。
立即学习“Java免费学习笔记（深入）”；
- 必须显式同步整个操作块：
synchronized (syncMap) { if (!syncMap.containsKey(key)) { syncMap.put(key, value); } } - 迭代必须手动同步：
synchronized (syncMap) { for (Map.Entry<K,V> e : syncMap.entrySet()) { // ... } } - 相比
ConcurrentHashMap，吞吐量在高并发下明显下降，尤其写多场景
CopyOnWriteArrayList 适合 Map 吗？
不适合。Java 没有 CopyOnWriteMap 标准实现，也不推荐自己封装。因为 CopyOnWrite 的核心代价是每次写都复制整个底层数组，对键值对集合来说内存和 CPU 开销过大，且无法保证 key-value 关联的原子性。
如果真需要类似语义（读极多、写极少、容忍短暂不一致），可考虑：
- 用
volatile引用指向不可变Map（如Map.copyOf(map)或ImmutableMap） - 读取时直接访问 volatile 引用；写入时重建新 map 并原子更新引用
- 注意：这种模式下，写操作不是线程安全的，需额外同步写入口
ConcurrentHashMap 的 computeXXX 方法怎么避坑
computeIfAbsent、computeIfPresent 等方法看似方便，但容易因函数副作用或阻塞导致死锁或性能恶化——它们在持有内部锁期间执行传入的 remappingFunction。
- 禁止在 lambda 中调用本 map 的其他修改方法（如再调
put），可能引发死锁 - 避免耗时操作（如 IO、远程调用），否则会拖慢整个桶的写入，影响并发度
- 若计算逻辑可能抛异常，需确保异常处理得当；未捕获异常会导致本次操作失败，且锁会被释放，但 map 状态不变
- 示例安全用法：
map.computeIfAbsent(key, k -> { // 快速构造新值，不访问 map 自身 return new ExpensiveObject(k); });
