CopyOnWriteArrayList

最新推荐文章于 2024-08-21 15:01:32 发布

楠楠灬虎虎

最新推荐文章于 2024-08-21 15:01:32 发布

阅读量174

点赞数

分类专栏：源码学习

本文链接：https://blog.csdn.net/zxh476771756/article/details/79788266

版权

源码学习专栏收录该内容

1 篇文章 0 订阅

订阅专栏

什么是CopyOnWrite容器

CopyOnWrite容器即写时复制的容器。通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。

CopyOnWriteArrayList的实现原理

 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();
        }
    }

读的时候不需要加锁，如果读的时候有多个线程正在向ArrayList添加数据，读还是会读到旧的数据，因为写的时候不会锁住旧的ArrayList。

    public E get(int index) {
        return get(getArray(), index);
    }

CopyOnWrite的缺点

CopyOnWrite容器有很多优点，但是同时也存在两个问题，即内存占用问题和数据一致性问题。所以在开发的时候需要注意一下。

内存占用问题。因为CopyOnWrite的写时复制机制，所以在进行写操作的时候，内存里会同时驻扎两个对象的内存，旧的对象和新写入的对象（注意:在复制的时候只是复制容器里的引用，只是在写的时候会创建新对象添加到新容器里，而旧容器的对象还在使用，所以有两份对象内存）。如果这些对象占用的内存比较大，比如说200M左右，那么再写入100M数据进去，内存就会占用300M，那么这个时候很有可能造成频繁的Yong GC和Full GC。之前我们系统中使用了一个服务由于每晚使用CopyOnWrite机制更新大对象，造成了每晚15秒的Full GC，应用响应时间也随之变长。

针对内存占用问题，可以通过压缩容器中的元素的方法来减少大对象的内存消耗，比如，如果元素全是10进制的数字，可以考虑把它压缩成36进制或64进制。或者不使用CopyOnWrite容器，而使用其他的并发容器，如ConcurrentHashMap。

数据一致性问题。CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果你希望写入的的数据，马上能读到，请不要使用CopyOnWrite容器。

copyOnWriter的其他应用

CopyOnWriter是一种常见的计算机程序设计领域的优化策略，例如redis里面的持久化机制。redis处理数据是通过单线程的，但是很多场景我们需要持久化数据，reids则依赖系统的fork()函数的copyOnWriter实现。

redis官方文档：

Whenever Redis needs to dump the dataset to disk, this is what happens:

Redis forks. We now have a child and a parent process.

The child starts to write the dataset to a temporary RDB file.

When the child is done writing the new RDB file, it replaces the old one.

This method allows Redis to benefit from copy-on-write semantics.