JDK源码阅读_集合框架(3)_线程安全的List

/ 默认分类 / 0 条评论 / 1080浏览

集合框架JDK源码java并发编程

JDK源码阅读_集合框架(3)_线程安全的List

前面的文章，我们分析了ArrayList和LinkedList的源码，他们都是线程不安全的，下面我们介绍下，在List中怎样使用线程安全的集合

1. Vector

Vector也集成了AbstractList，是List的一个实现类，其中的操作集合的方法都是经过synchronized修饰过的同步方法

2. java.util.Collections.synchronizedList(list)

Collections.synchronizedList(list)方法也是返回一个封装的集合对象，该集合对象中的操作方法也是使用synchronized来实现线程安全的

Collections是操作集合的工具类，其中不仅可以生成同步的List还有如下方法

需要注意的是，使用该方法生成的集合，迭代器中的操作仍然需要程序员自己进行线程安全的控制

     * Returns a synchronized (thread-safe) list backed by the specified
    * list.  In order to guarantee serial access, it is critical that
    * <strong>all</strong> access to the backing list is accomplished
    * through the returned list.<p>
    *
    * It is imperative that the user manually synchronize on the returned
    * list when iterating over it:
    * <pre>
    *  List list = Collections.synchronizedList(new ArrayList());
    *      ...
    *  synchronized (list) {
    *      Iterator i = list.iterator(); // Must be in synchronized block
    *      while (i.hasNext())
    *          foo(i.next());
    *  }
    * </pre>
    * Failure to follow this advice may result in non-deterministic behavior.
    *
    * <p>The returned list will be serializable if the specified list is
    * serializable.

3. CopyOnWriteArrayList

上面介绍的实现线程安全的List集合在读数据的时候也是加了锁的，是保证绝对的线程安全，jdk1.5中引入了另一个实现类CopyOnWriteArrayList，看到这个类你可能会想到之前我文章中介绍linux fork()函数时提到的写时复制（copy-on-write)，但是这里的写时复制原则使用在集合框架中是完全不同的逻辑

在Linux中进程的内存管理使用到的写时复制原则，目的是为了节省进程创建的开销，减少物理内存的使用，但是在java的集合框架中，copyonwrite的含义可能不大相同，具体我们来看下CopOnWriteArrayList的实现：

CopOnWriteArrayList 是对ArrayList的一个修改版，在CopOnWriteArrayList中，修改集合结构的操作（增加，删除）是线程安全的，其他的一些不同点，下面我们一一来分析：

  1. CopOnWriteArrayList简单查看

CopOnWriteArrayList中，元素都存储在volatile修饰的数组对象中，至于为什么是volatile修饰的，后面会分析，这里需要知道的是 CopOnWriteArrayList是支持随机访问的，实现了RandomAcess接口，并且从下面的方法可以看出来，在CopOnWriteArrayList中获取array变量 只能通过getArray和setArray方法，另外这里还声明了一个全局的final类型的ReentrantLock锁变量

public class CopyOnWriteArrayList<E>
    implements List<E>, RandomAccess, Cloneable, java.io.Serializable {
    
    /** The lock protecting all mutators */
    final transient ReentrantLock lock = new ReentrantLock();

    /** The array, accessed only via getArray/setArray. */
    private transient volatile Object[] array;

    /**
     * Gets the array.  Non-private so as to also be accessible
     * from CopyOnWriteArraySet class.
     */
    final Object[] getArray() {
        return array;
    }

    /**
     * Sets the array.
     */
    final void setArray(Object[] a) {
        array = a;
    }
  1. 如何实现的线程安全

    public boolean add(E e) {
        final ReentrantLock lock = this.lock;
        //加同步锁，没有获取到锁的线程需要等待
        lock.lock();
        try {
            //获取到现有的元素数组
            Object[] elements = getArray();
            int len = elements.length;
            //复制一份元素数组副本，并且这里时扩容了，大小增加了1，这里也是和ArrayList的一个不同，先来看ArrayList为什么要1.5倍的扩，因为下次省的再扩，而copyonwritearraylist不一样，为了使迭代器达到最安全的状态，每次修改操作都复制，直接扩大哦1.5倍没有意义
            Object[] newElements = Arrays.copyOf(elements, len + 1);
            newElements[len] = e;
            //将新的副本元素数组对象赋值给CopyOnWriteArrayList中真实的元素数组  
            setArray(newElements);
            return true;
        } finally {
            lock.unlock();
        }
    }

可以看到，在写操作的时候，进行了加锁，然后再复制副本后修改副本数据，再将副本赋值给真实变量；

  1. 为什么要使用volatile修饰array变量?

因为每个线程对array进行改变都是复制一个副本然后将新的副本赋值给它，为了让其他线程可以及时看到修改后的新值，所以使用volatile修饰，保证线程可见性（具体关于并发编程中的原子性和可见性原理分析可以搜索我的博客）

  1. 为什么要再写的时候进行复制? 先看这段代码：
static final class COWIterator<E> implements ListIterator<E> {
        /** Snapshot of the array */
        private final Object[] snapshot;
        /** Index of element to be returned by subsequent call to next.  */
        private int cursor;

        private COWIterator(Object[] elements, int initialCursor) {
            cursor = initialCursor;
            snapshot = elements;
        }

        public boolean hasNext() {
            return cursor < snapshot.length;
        }

        public boolean hasPrevious() {
            return cursor > 0;
        }

        @SuppressWarnings("unchecked")
        public E next() {
            if (! hasNext())
                throw new NoSuchElementException();
            return (E) snapshot[cursor++];
        }

        @SuppressWarnings("unchecked")
        public E previous() {
            if (! hasPrevious())
                throw new NoSuchElementException();
            return (E) snapshot[--cursor];
        }

        public int nextIndex() {
            return cursor;
        }

        public int previousIndex() {
            return cursor-1;
        }

        /**
         * Not supported. Always throws UnsupportedOperationException.
         * @throws UnsupportedOperationException always; {@code remove}
         *         is not supported by this iterator.
         */
        public void remove() {
            throw new UnsupportedOperationException();
        }

        /**
         * Not supported. Always throws UnsupportedOperationException.
         * @throws UnsupportedOperationException always; {@code set}
         *         is not supported by this iterator.
         */
        public void set(E e) {
            throw new UnsupportedOperationException();
        }

        /**
         * Not supported. Always throws UnsupportedOperationException.
         * @throws UnsupportedOperationException always; {@code add}
         *         is not supported by this iterator.
         */
        public void add(E e) {
            throw new UnsupportedOperationException();
        }

        @Override
        public void forEachRemaining(Consumer<? super E> action) {
            Objects.requireNonNull(action);
            Object[] elements = snapshot;
            final int size = elements.length;
            for (int i = cursor; i < size; i++) {
                @SuppressWarnings("unchecked") E e = (E) elements[i];
                action.accept(e);
            }
            cursor = size;
        }
    }

说实话，这也是我起初疑问的地方，但我的疑问不是为什么要这样做，而是为什么要用这种方式
首先，再ArrayList中，如果在读的时候，比如遍历迭代的时候，有其他线程对集合数据进行了修改操作，那么遍历的迭代器就会抛出ConcurrentModificationException异常，上篇文章说过，这是fail-fast快速失败机制，防止在迭代的过程中出现不可预期的问题，因为迭代初始的预期数据已经被篡改了； 那么CopOnWriteArrayList就想出一个好办法，每次进行修改操作都拷贝一个新的副本，在副本中进行修改，修改完毕后再将修改的副本赋值给真实数据，这样，迭代器初始化的一瞬间，它获取到的时集合的那一时刻的快照数据，如果再这期间有其他线程对集合框架进行了修改操作，也不会影响那一时刻的数据，因为修改后的数据已经不是那一时刻的对象本身，那一时刻的数据对象本身没有修改，只是修改了副本，然后将栈中的变量指向了堆中的副本，但是迭代器中栈中的变量还是指向堆中的那一时刻的数据；如下图

参考书本原文：

再回到 CopyOnWriteArrayList 的问题。CopyOnWriteArrayList 的写操作进行了加锁。如果 CopyOnWriteArrayList  
只有写操作，那么这里确实只通过加锁就可以保证安全，不需要进行复制。但是 CopyOnWriteArrayList 还有读操作，而且大多数情况下，List 
都是读多写少的。所以这里本质上也依然是并发读写的问题：  


若没有复制，写时加锁，读时不加锁，那么就会发生并发读写问题，产生不可预期的异常，即上面说的 ConcurrentModificationException； 
若没有复制，写时加锁，读时也需要加锁，这样就相当于退化为 SynchronizedList，读性能大大减弱。  
而写时复制，则可以很好的处理并发读写问题，而且还保障了性能：  


写时加锁，不会产生并发写的问题，保证了写操作的安全性；  
实际的写操作，是在复制的新数组上进行；而同一时刻的读操作，是在原数组进行的，所以这里的读操作不会产生并发读写问题，也不需要加锁  ；
新数组操作完成后，将原数组替换，这里则是通过 volatile 关键字保障了新数组的线程可见性。  

这样，引入写时复制的原因就说清楚了。实际上，这是   volatile、锁、写时复制三者共同作用的结果，既保证了并发读写的安全性，也保证了读的性能，三者缺一不可，可谓精妙。

关于CopyOnWriteArrayList的优缺点和合适的使用场景

①、CopyOnWriteArrayList，写数组的拷贝，支持高效率并发且是线程安全的,读操作无锁的ArrayList。所有可变操作都是通过对底层数组进行一次新的复制来实现。
②、CopyOnWriteArrayList适合使用在读操作远远大于写操作的场景里，比如缓存。它不存在扩容的概念，每次写操作都要复制一个副本，在副本的基础上修改后改变Array引用。CopyOnWriteArrayList中写操作需要大面积复制数组，所以性能肯定很差。
③、CopyOnWriteArrayList 合适读多写少的场景，不过这类慎用 ，因为谁也没法保证CopyOnWriteArrayList 到底要放置多少数据，万一数据稍微有点多，每次add/set都要重新复制数组，这个代价实在太高昂了。在高性能的互联网应用中，这种操作分分钟引起故障。

缺点：
1、由于写操作的时候，需要拷贝数组，会消耗内存，如果原数组的内容比较多的情况下，可能导致young gc或者full gc。 （1、young gc ：年轻代（Young Generation）：对象被创建时，内存的分配首先发生在年轻代（大对象可以直接被创建在年老代），大部分的对象在创建后很快就不再使用，因此很快变得不可达，于是被年轻代的GC机制清理掉（IBM的研究表明，98%的对象都是很快消亡的），这个GC机制被称为Minor GC或叫Young GC。
2、年老代（Old Generation）：对象如果在年轻代存活了足够长的时间而没有被清理掉（即在几次Young GC后存活了下来），则会被复制到年老代，年老代的空间一般比年轻代大，能存放更多的对象，在年老代上发生的GC次数也比年轻代少。当年老代内存不足时，将执行Major GC，也叫 Full GC ）

2、不能用于实时读的场景，像拷贝数组、新增元素都需要时间，所以调用一个set操作后，读取到数据可能还是旧的,虽然CopyOnWriteArrayList 能做到最终一致性（弱一致性）,但是还是没法满足实时性要求；

总结

所以CopOnWriteArrayList有点像，mysql中的可重复读，而synchronizedList直接读写通通加锁，有点像串行化，而ArrayList有点像不可重复读，但是这个不可重复读，使用了fail-fast机制，如果数据发生了篡改就直接不让你读了

疑问？

这里我有一个疑问就是，为什么不直接给修改操作加上锁，但是不复制，但是在迭代操作的时候会复制一份数据到迭代器中作为快照数据，这样也可以实现数据的可重复读取,并且可以减少写的内存消耗，只不过在读得到时候就需要复制了，所以CopyOnWriteArrayList就是专门为读多写少的场景设定的吗？

关于写时复制参考文章：
写时复制

本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名,转载请标明出处
最后编辑时间为: 2021/05/17 00:10