Java 并发容器的性能基准测试：ConcurrentHashMap、CopyOnWriteArrayList 的吞吐深度对比与选型指南

Java 并发容器的性能基准测试：ConcurrentHashMap、CopyOnWriteArrayList 的吞吐深度对比与选型指南

一、并发容器的"够用"幻象——当 HashTable 被 ConcurrentHashMap 取代后，谁来取代 ConcurrentHashMap？

Java 并发的容器家族经历了从Vector/HashTable（全局 synchronized）到ConcurrentHashMap/CopyOnWriteArrayList（分段锁/CAS）的演进。大多数开发者的认知停留在"用 ConcurrentHashMap 替代 HashTable"这一层，但很少有人进一步追问：在具体的使用场景下，ConcurrentHashMap 是否真的是最优解？

生产环境中存在大量"够用但不优"的容器选择。一个典型的案例：某广告推荐服务使用ConcurrentHashMap<String, List<Ad>>来缓存用户特征对应的广告列表，读频率极高（QPS 50000+），写频率中等（每分钟更新约 200 次）。这个设计看似合理，但 ConcurrentHashMap 中存储的ArrayList每次更新都需要整个 List 替换，在多线程读写下产生了不必要的 GC 压力。而CopyOnWriteArrayList因每次写入都复制整个数组，在这种场景下的写入成本过高。

"够用"是工程中值得尊重的原则，但前提是开发者确切地知道自己在做什么权衡。本文通过 JMH 基准测试，对 ConcurrentHashMap 和 CopyOnWriteArrayList 在不同读写比例下的吞吐做量化对比。

二、内部机制差异——分段锁时代之后的分治策略

ConcurrentHashMap 在 JDK 8 之后抛弃了 ReentrantLock 分段锁，转向 CAS + synchronized 的混合策略。Node 数组中的每个桶（bin）在冲突较少时通过 CAS 进行无锁插入，桶内链表长度超过阈值（8）时转为红黑树，对树的并发操作通过 synchronized 保护。

CopyOnWriteArrayList 的设计哲学完全不同。它维护一个volatile修饰的内部数组引用，所有读操作不加锁直接返回当前数组快照，所有写操作在复制的新数组上执行完成后原子性地替换引用：

两种容器的性能差异根源于它们解决的是不同问题：ConcurrentHashMap 追求读写并发的均衡，适合"读多写多"的场景；CopyOnWriteArrayList 追求读的极致性能，以写的高成本作为交换，适合"读远大于写"的场景。但"远大于"是多大？这正是基准测试需要回答的问题。

三、JMH 基准测试——量化不同读写比例下的真实吞吐

@State(Scope.Benchmark) @BenchmarkMode(Mode.Throughput) @OutputTimeUnit(TimeUnit.SECONDS) public class ConcurrentContainerBenchmark { private ConcurrentHashMap<Integer, AdData> chm; private CopyOnWriteArrayList<AdData> cowList; private static final int DATA_SIZE = 10_000; @Setup(Level.Trial) public void setup() { chm = new ConcurrentHashMap<>(); cowList = new CopyOnWriteArrayList<>(); for (int i = 0; i < DATA_SIZE; i++) { AdData ad = new AdData(i, "ad_" + i); chm.put(i, ad); cowList.add(ad); } } /** * 纯读场景（100% Read）： * ConcurrentHashMap 和 CopyOnWriteArrayList 的随机读取。 */ @Benchmark public AdData concurrentHashMap_randomRead(ThreadState state) { return chm.get(state.randomIndex()); } @Benchmark public AdData copyOnWriteArrayList_randomRead() { // COWList 的随机访问：O(1) 数组访问 + volatile 引用读取 int idx = ThreadLocalRandom.current().nextInt(cowList.size()); return cowList.get(idx); } /** * 纯写场景（100% Write）： * ConcurrentHashMap 和 CopyOnWriteArrayList 的更新/替换操作。 */ @Benchmark public void concurrentHashMap_update(ThreadState state) { int idx = state.randomIndex(); chm.compute(idx, (k, v) -> new AdData(k, "updated_" + k)); } @Benchmark public void copyOnWriteArrayList_update() { // COWList 的更新：先查找索引再 set（内部仍为数组复制） int idx = ThreadLocalRandom.current().nextInt(cowList.size()); cowList.set(idx, new AdData(idx, "updated_" + idx)); } /** * 混合读写场景（50% Read + 50% Write）： * 每两次操作中执行一次读一次写。 */ @Benchmark @Group("chmMixed") @GroupThreads(4) public void chm_read(ThreadState state) { chm.get(state.randomIndex()); } @Benchmark @Group("chmMixed") @GroupThreads(4) public void chm_write(ThreadState state) { int idx = state.randomIndex(); chm.put(idx, new AdData(idx, "mixed_" + idx)); } @State(Scope.Thread) public static class ThreadState { int[] indices; @Setup(Level.Trial) public void setup() { indices = new int[1000]; for (int i = 0; i < indices.length; i++) { indices[i] = ThreadLocalRandom.current().nextInt(DATA_SIZE); } } int randomIndex() { return indices[ThreadLocalRandom.current().nextInt(indices.length)]; } } public static void main(String[] args) throws RunnerException { Options opt = new OptionsBuilder() .include(ConcurrentContainerBenchmark.class.getSimpleName()) .warmupIterations(3) .measurementIterations(5) .forks(1) .threads(8) .build(); new Runner(opt).run(); } }

在 8 核 16G 机器上的实测结果（吞吐量单位 ops/us）：

数据揭示了清晰的规律：在纯读场景中，CopyOnWriteArrayList 由于零锁开销，读吞吐比 ConcurrentHashMap 高出 50%。但一旦引入写入，CopyOnWriteArrayList 的性能呈断崖式下降——纯写场景吞吐仅为 ConcurrentHashMap 的 1/27，混合场景约为 1/24。这是因为每次写入都需要Arrays.copyOf复制 10000 个元素，而 ConcurrentHashMap 仅锁定单个桶。

四、适用边界与"写频率阈值"的量化

基于测试数据，可以推导出一个简单的选型阈值公式：

当写入操作占总操作比例 < 5% 时，CopyOnWriteArrayList 的读写综合吞吐与 ConcurrentHashMap 相当或更优。当写入比例 > 10% 时，CopyOnWriteArrayList 的写复制成本开始显著拖累整体吞吐，ConcurrentHashMap 是明确的选择。

这个阈值并非绝对，它还与数据规模正相关。对于仅有 100 个元素的小型集合，Arrays.copyOf的成本可以忽略（约 1-2 微秒），CopyOnWriteArrayList 的写入比例阈值可提高到 20%。对于 10 万个元素的大型集合，每次复制的成本约 50-100 微秒，即使写入比例仅 1%，CPU 利用率也可能受到不可忽视的影响。

另一个容易忽视的陷阱是 CopyOnWriteArrayList 的迭代器一致性语义。迭代器创建时获取的是数组快照，迭代过程中对集合的修改对迭代器不可见。这一特性在某些业务场景中是有意利用的特性，在另一些场景中则是数据不一致的源头。

适合 CopyOnWriteArrayList 的典型场景：配置信息缓存（启动时全量写入后极少变更）、监听器列表（注册后很少移除）、黑名单过滤（定期更新）。适合 ConcurrentHashMap 的典型场景：高并发缓存、实时计数器、需要原子复合操作（computeIfAbsent）的有状态存储。

五、总结

并发容器的选型不能仅凭"ConcurrentHashMap 替代 HashTable"的惯性决策。CopyOnWriteArrayList 在纯读或读主导场景中的零锁优势在数据规模小时尤为明显，但写入比例一旦超过 5%-10%，其复制开销就会成为性能瓶颈。建议在选型前基于实际数据规模和读写比例做一次 JMH 微基准测试，用数据而非直觉做决策。对于无法确定比例的动态场景，ConcurrentHashMap 因其在各类负载下表现均衡，是一个安全的默认选择。