copyonwritearraylist通过写时复制实现弱一致性与高并发读性能，读操作零阻塞、迭代安全，但写操作需复制整个数组，带来内存与gc压力；适用于读多写少、数据量小、允许短暂不一致的配置类场景。

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 只存它的引用，进一步降低复制负担