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

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

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就是专门为读多写少的场景设定的吗?

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