别再让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操作时线程A检查容量足够(size9)线程B也检查容量(size9)线程A执行elementData[size] e (size变为10)线程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会带来明显的性能问题。我们做了一个基准测试对比操作类型线程数平均耗时(ms)纯写入10125纯读取1098读写混合10217当读操作占80%以上时synchronizedList的性能下降明显。这时我们可以考虑以下优化方案缩小同步块范围只对必要的代码段加锁使用读写锁(ReentrantReadWriteLock)考虑使用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(); } }关键点在于写入时复制一个新数组在新数组上执行修改原子性地替换引用3.2 内存消耗与性能权衡我们同样做了性能测试场景写入耗时读取耗时100万次写入2150ms-100万次读取-45ms90%读10%写混合320ms28ms从数据可以看出写入性能较差(因为要复制数组)读取性能极佳(无锁)适合读多写少的场景在配置中心、黑白名单等读多写少的场景中CopyOnWriteArrayList的表现非常出色。我曾用它优化过一个配置服务QPS从2000提升到了15000。4. 实战选型指南根据场景选择最佳方案4.1 决策矩阵考虑因素synchronizedListCopyOnWriteArrayList写操作频率高优低优读操作频率中高优内存敏感度高优低优数据一致性要求强一致最终一致单个元素大小不影响大对象影响显著4.2 典型场景建议实时交易系统写操作频繁要求强一致 → synchronizedList配置中心读多写少允许短暂不一致 → CopyOnWriteArrayList日志收集系统写入量大但允许少量丢失 → 考虑ConcurrentLinkedQueue缓存系统读远多于写数据量大 → CopyOnWriteArrayList分片4.3 高级技巧混合使用策略在某些复杂场景下可以结合使用两种方案。例如在电商商品评价系统中// 热点评价列表(读多写少) private ListComment hotComments new CopyOnWriteArrayList(); // 待审核评价(写多读少) private ListComment pendingComments Collections.synchronizedList(new ArrayList());这种混合策略在实际项目中往往能取得最佳效果。去年双十一大促期间我们通过这种设计成功支撑了每秒10万的评价读取请求。