Java并发编程之美——第四章 Java并发包中原子操作类原理剖析
Java并发编程之美——第三章 Java并发包中ThreadLocalRandom类原理剖析
文章目录
**CopyOnWriteArrayList是J.U.C下的一个线程安全的ArrayList.**
Time 2021-12-30——Hireek
类图
除了RandomAccess,其他接口我相信大家都很熟悉,实现RandomAccess的标识list支持快速访问策略(for循环比iterator快)。
public E set(int index, E element)
增删改,我们就只看看修改这个方法,大同小异。
/**
* Replaces the element at the specified position in this list with the
* specified element.
*
* @throws IndexOutOfBoundsException {@inheritDoc}
*/
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/
写时复制策略产生的弱一致性问题
/**
* {@inheritDoc}
*
* @throws IndexOutOfBoundsException {@inheritDoc}
*/
public E get(int index) {
return get(getArray(), index);
}
读是没有加任何锁的,读并不是一个原子操作。读的时候刚好还没修改完,由于修改的时候总是会拷贝一份进行修改,读的就是写之前的旧数据。这就是弱一致性问题。如果读操作对于实时性有特别高的要求,不建议使用。
内存占用问题,gc频繁回收,因为写操作总是拷贝数据,如果数组里的元素(对象)特别大,带来的垃圾回收的代价还是比较大的。
与Collections.synchronizedList(new ArrayList()性能对比
SynchronizedList加锁方式。
public E set(int index, E element) {
synchronized (mutex) {return list.set(index, element);}
}
由加锁方式,写操作都是互斥锁实现,但是CopyOnWriteArrayList多了一个拷贝步骤。<SynchronizedList。
而读又没有加锁,>SynchronizedList。
所以,CopyOnWriteArrayList适合读多写少的场景,并且对数据的实时性要求不高。
加油,期待蓝天的少年总抬头!