别再让ArrayList在多线程里‘丢数据’了！手把手教你选对synchronizedList和CopyOnWriteArrayList

多线程环境下ArrayList的线程安全陷阱与解决方案实战

上周团队里刚转正的同事小张遇到了一个诡异的问题——他负责的订单统计模块在高峰期总是少算数据。监控日志显示没有任何异常抛出，但最终结果却比实际少了15%-20%。当我帮他排查时，发现他正在多线程环境下直接使用ArrayList记录订单ID。"这不就是经典的线程安全问题吗？"我指着屏幕上的ArrayList说道。本文将带你彻底理解这个"隐形杀手"的工作原理，并掌握两种专业解决方案的实战应用技巧。

1. ArrayList为何在多线程中"丢数据"：深入JVM层面的原理剖析

让我们先还原小张遇到的场景。他创建了10个线程并行处理订单，每个线程成功处理一个订单后，就会将订单ID添加到一个共享的ArrayList中。理论上如果有1000个订单处理成功，ArrayList的size()应该返回1000，但实际运行结果却在800-950之间随机波动。

1.1 从字节码看size++的非原子性

问题的根源在于ArrayList的add()方法实现。当我们查看编译后的字节码时，会发现看似简单的size++操作实际上由多个步骤组成：

aload_0 // 将this引用压入操作数栈 dup // 复制栈顶元素 getfield #2 // 获取size字段的值 iconst_1 // 将常量1压入栈 iadd // 执行加法运算 putfield #2 // 将结果写回size字段

在多线程环境下，两个线程可能同时读取到相同的size值，执行加1操作后写回，导致实际只增加了一次。这就解释了为什么最终size会小于预期值。

1.2 数组越界的隐藏风险

更危险的是可能发生的ArrayIndexOutOfBoundsException。ArrayList内部使用Object[]数组存储元素，当多个线程同时执行add操作时：

1. 线程A检查容量足够(size=9)
2. 线程B也检查容量(size=9)
3. 线程A执行elementData[size++] = e (size变为10)
4. 线程B尝试执行elementData[10] = e 但数组长度可能只有10

这种情况在压力测试时可能表现为偶发的崩溃，而在生产环境可能直接导致请求失败。

实际项目中，这类问题往往在流量突增时突然出现。我曾见过一个电商系统在大促时因此丢失了20%的秒杀订单记录。

2. Collections.synchronizedList的锁机制与适用场景

Java集合框架提供了Collections.synchronizedList()方法来创建线程安全的List。它的实现原理很简单：在所有修改操作上加同步锁。

2.1 同步锁的实现细节

查看其源码可以看到：

public boolean add(E e) { synchronized (mutex) { return c.add(e); } }

这个mutex对象就是同步锁，所有操作都会先获取这个锁。这种方式的优点是：

• 实现简单直接
• 保证绝对的线程安全
• 适合写操作频繁的场景

2.2 性能瓶颈与优化建议

但在高并发读场景下，synchronizedList会带来明显的性能问题。我们做了一个基准测试对比：

当读操作占80%以上时，synchronizedList的性能下降明显。这时我们可以考虑以下优化方案：

1. 缩小同步块范围：只对必要的代码段加锁
2. 使用读写锁(ReentrantReadWriteLock)
3. 考虑使用CopyOnWriteArrayList(下一节介绍)

3. CopyOnWriteArrayList的写时复制机制解析

CopyOnWriteArrayList是JUC包中提供的线程安全List实现，它采用了一种巧妙的设计思想：写时复制(Copy-On-Write)。

3.1 核心实现原理

其add方法实现如下：

public boolean add(E e) { final ReentrantLock lock = this.lock; lock.lock(); try { Object[] elements = getArray(); int len = elements.length; Object[] newElements = Arrays.copyOf(elements, len + 1); newElements[len] = e; setArray(newElements); return true; } finally { lock.unlock(); } }

关键点在于：

1. 写入时复制一个新数组
2. 在新数组上执行修改
3. 原子性地替换引用

3.2 内存消耗与性能权衡

我们同样做了性能测试：

从数据可以看出：

• 写入性能较差(因为要复制数组)
• 读取性能极佳(无锁)
• 适合读多写少的场景

在配置中心、黑白名单等读多写少的场景中，CopyOnWriteArrayList的表现非常出色。我曾用它优化过一个配置服务，QPS从2000提升到了15000。

4. 实战选型指南：根据场景选择最佳方案

4.1 决策矩阵

4.2 典型场景建议

1. 实时交易系统：写操作频繁，要求强一致 → synchronizedList
2. 配置中心：读多写少，允许短暂不一致 → CopyOnWriteArrayList
3. 日志收集系统：写入量大但允许少量丢失 → 考虑ConcurrentLinkedQueue
4. 缓存系统：读远多于写，数据量大 → CopyOnWriteArrayList+分片

4.3 高级技巧：混合使用策略

在某些复杂场景下，可以结合使用两种方案。例如在电商商品评价系统中：

// 热点评价列表(读多写少) private List<Comment> hotComments = new CopyOnWriteArrayList<>(); // 待审核评价(写多读少) private List<Comment> pendingComments = Collections.synchronizedList(new ArrayList<>());

这种混合策略在实际项目中往往能取得最佳效果。去年双十一大促期间，我们通过这种设计成功支撑了每秒10万+的评价读取请求。