CopyOnWriteArrayList：分析写时复制机制在“读多写少”场景下的弱一致性保证与内存开销

CopyOnWriteArrayList 的写时复制机制，本质上就是一场精心设计的“交易”——拿空间换时间，用弱一致性来换取高并发下的读性能。它从来不会拍胸脯保证每次读到的都是绝对最新的数据，但能确保读操作永远不被阻塞、迭代过程安全可靠、系统整体稳定。实际上，这正是“读多写少”场景下最合理的一种取舍。

弱一致性是怎么体现的

弱一致性说白了就是：读操作看到的数据可能不是最新版本，但一定是某一个确定时刻的完整快照。 - 每次调用 **get()** 或者创建 **iterator()** 时，都直接读取当前 volatile 引用指向的那个数组，不加锁，也不同步——干净利落。 - 写操作（像 add、remove）则要先加锁，把整个数组复制一份，在副本上修改，最后原子更新引用。这个过程耗时，但正在读的线程完全不受影响。 - 迭代器一旦创建，就牢牢绑定到那一刻的数组快照上；后续其他线程再怎么写，这个迭代器都“看不见”，各玩各的。 - 所以多个线程同时读到不同版本的数据，完全是设计预期：A 线程刚读完旧配置，B 线程紧接着读到新配置，这不算 bug，反而是并发读性能的代价。

内存开销从哪来

开销不是一次性埋单，而是每次写操作都会触发的一次性压力。核心原因就是数组复制和对象驻留。 - 每次写都要 new 一个长度为 **原数组长度 +1（或 -1）** 的新数组，然后逐个拷贝元素——哪怕只增删一个元素，也得把整个数组搬一遍。 - 旧数组不会立刻回收，得等 GC 判定它不可达。如果写频率稍微高一点（比如每秒几次），堆里就会堆积大量短生命周期的数组对象。 - 举个例子：假设配置项平均 200 字节，500 条就是约 100KB；一次写复制就要额外分配 100KB，一分钟写 10 次，就产生 1MB 临时对象。 - 频繁复制还会加剧 Young GC 压力，尤其在堆较小或对响应延迟敏感的服务里，很容易引起毛刺。

为什么还能接受这种“不一致”和“高开销”

原因很简单：代价被精准控制在低频写的入口，而收益覆盖了高频读的主干链路。 - 配置类数据本身变更极少：后台改一次开关，服务端可能被读取数万次。这时候只要一次复制就能换掉所有的读锁，划算到不行。 - 弱一致性完全可以接受：像路由规则、功能开关、限流阈值这类配置，延迟几百毫秒才生效，业务层面完全无感。 - 数据量可控是前提：一般控制在 500 条以内，复制开销还在亚毫秒级别；一旦超千条，单次写可能就升到几毫秒，那就失去意义了。 - 还有一点必须强调：配置项本身必须不可变。如果某个配置项是可变对象（比如包含可修改字段的 POJO），那快照就形同虚设——复制的只是引用，内容仍可能被其他线程改掉。

实际使用的关键提醒

不复杂，但容易踩坑。 - 别把它当成通用的线程安全 List 来用。写操作多、数据量大、要求强一致的场景，更适合用 ConcurrentHashMap 或 synchronizedList。 - 写操作尽量批量聚合。比如配置刷新时，不要一条一条地 add，而是构造一个新列表后，用 setArray（需要反射）或整体替换。 - 留意 GC 日志里的 Promotion Failure 或频繁 YGC——这很可能是 CopyOnWriteArrayList 写得太勤的信号。 - 更稳妥的做法是配合 volatile 配置对象使用：把整个配置封装成不可变类，CopyOnWriteArrayList 只存它的引用，这样能进一步降低复制负担。