Java并发编程之美——第五章 Java并发包中并发List源码剖析

• • Time 2021-12-30——Hireek
  • 类图
  • public E set(int index, E element)
  • 写时复制策略产生的弱一致性问题
  • 与Collections.synchronizedList(new ArrayList()性能对比

除了RandomAccess，其他接口我相信大家都很熟悉，实现RandomAccess的标识list支持快速访问策略（for循环比iterator快）。

增删改，我们就只看看修改这个方法，大同小异。

public E set(int index, E element) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        Object[] elements = getArray();
        E oldValue = get(elements, index);

        if (oldValue != element) { // (1)
            int len = elements.length;
            Object[] newElements = Arrays.copyOf(elements, len);
            newElements[index] = element;
            setArray(newElements);
        } else {
            // Not quite a no-op; ensures volatile write semantics
            setArray(elements); // (2)
        }
        return oldValue;
    } finally {
        lock.unlock();
    }
}

如上代码首先获取了独占锁（保证线程安全），从而阻止其他线程对array数组进行修改，然后获取当前数组，并调用get方法获取指定位置的元素，如果指定位置的元素值与新值不一致则创建新数组井复制元素，然后在新数组上修改指定位置的元素值并设置新数组到array。如果指定位置的元素值与新值一样，Not quite a no-op; ensures volatile write semantics，则为了保证volatile语义，还是需要重新设置array，虽然array的内容并没有改变。

想想volatile的语义，即可见性和内存屏障。具体见之前的第二章。我想应该是仅仅为了这个语义，因为是写操作。也可以参考：http://ifeve.com/copyonwritearraylist-set/

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

读是没有加任何锁的，读并不是一个原子操作。读的时候刚好还没修改完，由于修改的时候总是会拷贝一份进行修改，读的就是写之前的旧数据。这就是弱一致性问题。如果读操作对于实时性有特别高的要求，不建议使用。

内存占用问题，gc频繁回收，因为写操作总是拷贝数据，如果数组里的元素（对象）特别大，带来的垃圾回收的代价还是比较大的。

SynchronizedList加锁方式。

public E set(int index, E element) {
    synchronized (mutex) {return list.set(index, element);}
}

由加锁方式，写操作都是互斥锁实现，但是CopyOnWriteArrayList多了一个拷贝步骤。

而读又没有加锁，>SynchronizedList。

所以，CopyOnWriteArrayList适合读多写少的场景，并且对数据的实时性要求不高。

加油，期待蓝天的少年总抬头！