Java并发编程中的同步容器与多线程环境_技术教程

ConcurrentHashMap 更适合高并发场景，因其采用分段锁（JDK 7）或 CAS + synchronized 锁单个 Node（JDK 8+），读操作无锁、写操作细粒度加锁；而 Hashtable 使用全局 synchronized 锁，吞吐量低。

ConcurrentHashMap 为什么比 Hashtable 更适合高并发场景

因为 ConcurrentHashMap 不是简单地给整个表加锁，而是把哈希表分段（JDK 8 后改用 CAS + synchronized 锁单个 Node），读操

作完全无锁，写操作只锁必要节点。而 Hashtable 所有方法都用 synchronized 修饰，等同于一把全局锁，吞吐量在多线程下急剧下降。

实操建议：

除非遗留系统强制要求，否则永远优先选 ConcurrentHashMap 而非 Hashtable
ConcurrentHashMap 的 size() 和 isEmpty() 是弱一致性——可能反映的是某次快照状态，不适用于强校验逻辑
迭代时若其他线程修改了容器，不会抛 ConcurrentModificationException，但你看到的可能是过期数据

Vector 和 Collections.synchronizedList 的区别在哪

两者都提供线程安全的 List，但锁粒度不同：Vector 每个方法自带 synchronized，锁的是实例本身；Collections.synchronizedList(new ArrayList()) 则是对传入的 ArrayList 做装饰，所有方法也同步在同一个对象上。表面看没差别，但关键在于：它们都做不到复合操作原子化。

常见错误现象：

if (list.size() > 0) list.get(0); —— 这段代码即使在 Vector 或同步 List 中仍可能抛 IndexOutOfBoundsException，因为 size() 和 get() 是两次独立调用，中间可能被其他线程清空
想实现“不存在则添加”，不能靠 contains() + add() 组合，必须自己用外部同步块包裹

正确做法示例：

synchronized (list) {
    if (!list.contains(item)) {
        list.add(item);
    }
}

CopyOnWriteArrayList 适合什么场景，又为什么不能滥用

CopyOnWriteArrayList 在写操作（add、set、remove）时复制整个底层数组，读操作不加锁。它适合读远多于写的场景，比如监听器列表、配置白名单缓存。

但要注意：

每次写都触发数组复制，内存开销大，且随着集合变大，写延迟明显上升
迭代器基于创建时刻的快照，无法反映后续写入——所以它不适合需要实时感知变更的业务逻辑
不支持 Iterator.remove()，调用会抛 UnsupportedOperationException

同步容器的迭代器都不是 fail-fast 的，这带来什么实际影响

像 ConcurrentHashMap、CopyOnWriteArrayList、ConcurrentLinkedQueue 的迭代器，都不会在检测到并发修改时抛 ConcurrentModificationException。这不是 bug，是设计取舍：以牺牲强一致性换并发性能。

这意味着：

你不能依赖迭代异常来发现并发 bug；反而要主动审查是否遗漏了必要的同步边界
如果业务逻辑要求“遍历中必须看到最新状态”，这些容器都不适用，得考虑 ReentrantLock + 普通集合，或改用更高级的并发结构（如 StampedLock 读写锁）
测试时容易漏掉竞态问题——单元测试跑一次没问题，压测时才暴露数据不一致

真正棘手的从来不是“怎么选容器”，而是“哪些操作必须串行化”——这个判断往往藏在业务语义里，而不是 API 文档里。