CopyOnWriteArrayList:分析写时复制机制在“读多写少”场景下的弱一致性保证与内存开销
作者:WeekendFlower
时间:2026-07-06
浏览:0
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 只存它的引用,这样能进一步降低复制负担。
作者最新文章
赤友清理大师
2026-09-16 17:43
南邮光擎智算团队:GaN基Micro-LED光计算芯片从理论到流片的突破
2026-09-08 18:35
多张照片怎么合成PDF文件?三种图片转PDF工具怎么选?
2026-09-03 17:04
Excel转PDF防乱版指南:在线与本地双方案及排版检查
2026-09-03 10:04
多个PDF怎么合并成一个?合并后顺序怎么检查?
2026-09-02 19:54
热门文章
更多
精品专题
更多
Mac软件
更多
WINDOWS
更多


































