java arraylist 并发_由浅入深——从ArrayList浅谈并发容器

原创作品转载请附：https://www.cnblogs.com/superlsj/p/11655523.html

一、一个案例引发的思考

public classArrayListTest {public static voidmain(String[] args) {

List list = new ArrayList();for (int i = 1; i <= 50; i++) {new Thread(() ->{

list.add(UUID.randomUUID().toString().substring(0,8));

System.out.println(list);

}).start();

}

}

}

java.util.ConcurrentModificationException

at java.util.ArrayList$Itr.checkForComodification(Unknown Source)

at java.util.ArrayList$Itr.next(Unknown Source)

at java.util.AbstractCollection.toString(Unknown Source)

at java.lang.String.valueOf(Unknown Source)

at java.io.PrintStream.println(Unknown Source)

at com.qlu.test1.ArrayListTest.lambda$0(ArrayListTest.java:13)

at java.lang.Thread.run(Unknown Source)

即所谓的并发修改异常。我们先来分析一下为什么会报这个错。

二、错误产生的原因

我们知道，ArrayList是线程不安全的，它的所有方法没有加Synchronized锁：例如

public booleanadd(E e) {

ensureCapacityInternal(size+ 1); //Increments modCount!!

elementData[size++] =e;return true;

}

也就是说，上面定义的50个线程都会抢占此ArrayList。那么为什么会爆出错误呢？当我把System.out.println(list);删除后，错误就没报了。那么问题可能出在ArrayList的toString()方法。查看源码会发现

ArrayList类并没有toString()方法。这个toString方法是从ArrayList的父类的父类：AbstractCollection类继承而来的，toString()方法源码如下：

publicString toString() {

Iterator it =iterator();if (!it.hasNext())return "[]";

StringBuilder sb= newStringBuilder();

sb.append('[');for(;;) {

E e=it.next();

sb.append(e== this ? "(this Collection)": e);if (!it.hasNext())return sb.append(']').toString();

sb.append(',').append(' ');

}

}

toString()方法遍历集合所有的元素拼接了一个字符串返回。那么问题出在哪呢？首先记住两个变量：modCount和expectedModCount。

由上面的add方法的源码可以看到，在方法体内的先执行了ensureCapacityInternal(size + 1);方法，这个方法中调用了ensureExplicitCapacity()方法，而在此方法的第一行：赫然写着modCount++

private void ensureExplicitCapacity(intminCapacity) {

modCount++;//overflow-conscious code

if (minCapacity - elementData.length > 0)

grow(minCapacity);

}

也就是说集合的每一次添加操作都会触发modCount++操作，而并没有expectedModCount++，在来看一下expectedModCount是何时被赋值的：

在集合完成创建后，expectedModCount的值是0，在创建迭代器时将modCount的值赋给了expectedModCount：

private class Itr implements Iterator{int cursor; //index of next element to return

int lastRet = -1; //index of last element returned; -1 if no such

int expectedModCount =modCount;public booleanhasNext() {return cursor !=size;

}

......

而在迭代器创建以后，expectedModCount的值就不再改变。也就是说此后的add操作会改变modCount，而不会改变expectedModCount。那么重点来了。在使用迭代器的next()方法时，会调用checkForComodification()方法验证expectedModCount和modCount是否相等：

publicE next() {

checkForComodification();int i =cursor;if (i >=size)throw newNoSuchElementException();

Object[] elementData= ArrayList.this.elementData;if (i >=elementData.length)throw newConcurrentModificationException();

cursor= i + 1;return (E) elementData[lastRet =i];

}

checkForComodification()方法源码如下：如果 modCount != expectedModCount 不相等，就抛出并发修改异常。

final voidcheckForComodification() {if (modCount !=expectedModCount)throw newConcurrentModificationException();

}

在回到开头的案例：

for (int i = 1; i <= 50; i++) {new Thread(() ->{

list.add(UUID.randomUUID().toString().substring(0,8));

System.out.println(list);

}).start();

}

由于list是共享资源，即所有线程共享一个modCount资源。假设A线程添加一个UUID后，由于需要输出list，而输出list需要创建迭代器，此时他根据集合的modCount假设为2，那么expectedModCount也是2，但是A线程next()迭代集合拼接字符串的操作未完成，CPU就将资源转给了其他线程，假设转给了线程B，B拿到资源后由于进行了add操作，所以list的modCount++；假设modCount++后为3，虽然B线程创建迭代器时会根据最新的modCount给expectedModCount=3，但是如果此时CPU又将资源转给了线程A，线程A加载自己原先的上下文，或得上一次执行时的迭代器对象，而此迭代器对象持有的 expectedModCount为2，而共享资源里的modCount却被B线程更新到了3，此时如果A线程继续迭代next()，就会发现modCount != expectedModCount 不相等，就抛出并发修改异常。

三、如何解决问题

1、将ArrayList改成Vector，不再赘述。

2、使用集合工具类Collections

public classArrayListTest{public static voidmain(String[] args) {

List list = Collections.synchronizedList(new ArrayList<>());for (int i = 1; i <= 50; i++) {new Thread(() ->{

list.add(UUID.randomUUID().toString().substring(0,8));

System.out.println(list);

}).start();

}

}

}

此方法同样可以用于其他线程不安全的集合类，例如：set、map

3、使用并发容器【推荐使用】

public classArrayListTest{public static voidmain(String[] args) {

List list = new CopyOnWriteArrayList<>();for (int i = 1; i <= 50; i++) {new Thread(() ->{

list.add(UUID.randomUUID().toString().substring(0,8));

System.out.println(list);

}).start();

}

}

}

将ArrayList换成CopyOnWriteArrayList问题就解决了，CopyOnWriteArrayList是怎么解决问题的呢？这就要提到一个重要的技术：写时复制技术。

四、写时复制技术

ArrayList和CopyOnWriteArrayList，都是集合，都是通过add增加元素，那么区别到底在哪里呢？先来看看CopyOnWriteArrayList的add方法的源码。

public booleanadd(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();

}

}

与Vector不同的是：CopyOnWriteArrayList并没有采用传统的synchronized，而是采用了ReentrantLock可重入锁。关于锁的只是本章节不做讨论，这里主要研究写时复制技术是如何实现的。add方法先创建了一个Object类型的数组，指向了旧数组，然后定义变量len保存数组容量，由于此数组从length从0开始，每增加一个元素，扩容一单位，所以size=length。然后定义新数组newElements，长度为len+1，在给新数组的新增位置添加add方法传进来的新元素后，调用setArray方法将旧数组的引用指向这个新数组。

整个过程就像墙上贴着登记信息，传统的ArrayList的解决方法是：谁抢到登记表谁填信息，如果谁抢到后还没写完就被别人抢去了，那旧出现了数据不安全的问题。CopyOnWriteArrayList的解决方案就像是，第一个登记的将墙上的表格赋值一份到自己的线程私有的空间，等自己写完后就贴回墙上覆盖原来的表，内存是消耗了一点，但是绝对安全。在这个过程中还涉及了一个版本号的问题，假设此时两名名同学同时将墙上的空表(假设版本为1.0)复制一份自己填写姓名，但是张三明显会比诸葛孔明写得快，于是率先将自己的表贴到墙上覆盖了原表，并将表格版本提升到了2.0，而此时诸葛孔明写完了准备提交，JVM会校验版本信息，发现诸葛孔明不是基于最新版本的数据做的修改，所以修改无效，此时诸葛孔明同学就需要重新复制一份填写姓名。

这样的思想在软件设计时非常常见，Git在版本控制上也使用了这样的乐观锁技术。

附：新兵蛋子，如有错误，还请各位大哥指正。