AbstractList類中有一個(gè)屬性

protected transient int modCount = 0;

api中對(duì)它的描述是：

• 此列表已被結(jié)構(gòu)修改的次數(shù)。 結(jié)構(gòu)修改是改變列表大小的那些修改，或以其他方式擾亂它，使得正在進(jìn)行的迭代可能產(chǎn)生不正確的結(jié)果。
• 該字段由迭代器和列表迭代器實(shí)現(xiàn)使用，由iterator和listIterator方法返回。 如果該字段的值意外更改，迭代器（或列表迭代器）將拋出一個(gè)ConcurrentModificationException響應(yīng)next?，?remove?，?previous?，?set或add操作。 這提供了fail-fast行為，而不是面對(duì)在迭代期間的并發(fā)修改的非確定性行為

我的理解是，modCount表示了當(dāng)前列表結(jié)構(gòu)被修改的次數(shù)，在調(diào)用迭代器操作時(shí)，則會(huì)檢查這個(gè)值，如果發(fā)現(xiàn)已更改，拋出異常

不過(guò)需要注意的是transient修飾意味著這個(gè)屬性不會(huì)被序列化，而且modCount并沒(méi)有被voliate修飾，也就是它不能保證在線程之間是可見的

?

從ArraytList源碼中可以發(fā)現(xiàn)，add,remove,clear等方法實(shí)現(xiàn)時(shí)，均添加了modCount++;操作，例如clear方法：

public void clear() {modCount++;// clear to let GC do its workfor (int i = 0; i < size; i++)elementData[i] = null;size = 0;}

在arraylist中調(diào)用迭代器是通過(guò)內(nèi)部類實(shí)現(xiàn)的：

public Iterator<E> iterator() {return new Itr();}

在這個(gè)內(nèi)部類中，同樣維護(hù)了一個(gè)類似modCount的變量

int expectedModCount = modCount;

并提供了檢測(cè)方法

final void checkForComodification() {if (modCount != expectedModCount)throw new ConcurrentModificationException();}

這個(gè)檢測(cè)方法在迭代器中類似next方法里面作為首先需要判斷的條件

@SuppressWarnings("unchecked")public E next() {checkForComodification();int i = cursor;if (i >= size)throw new NoSuchElementException();Object[] elementData = ArrayList.this.elementData;if (i >= elementData.length)throw new ConcurrentModificationException();cursor = i + 1;return (E) elementData[lastRet = i];}

我們綜合以上，就可以得出，

在使用迭代器遍歷arraylist時(shí)，會(huì)初始化一個(gè)和modCount相等的變量，如果在迭代過(guò)程中，arraylist中發(fā)生了類似add這種改變結(jié)構(gòu)的操作(modCount改變)，導(dǎo)致modCount != expectedModCount，那么會(huì)拋出一個(gè)異常ConcurrentModificationException，即產(chǎn)生fail-fast事件

?

產(chǎn)生fail-fast有兩種原因:

1.單線程情況下，迭代的過(guò)程中，調(diào)用類似add方法，但是一般不會(huì)這樣做

　　　　 ArrayList<Integer> al = new ArrayList<>();for(int i=0;i<10;i++)al.add(i);Iterator<Integer> it = al.iterator();while(it.hasNext()) {System.out.println(it.next());if(!it.hasNext())al.add(10);}

?

2.主要發(fā)生在多線程情況下，例如讓線程1迭代，線程2修改，就有可能會(huì)出現(xiàn)

final ArrayList<Integer> al = new ArrayList<>();for(int i=0;i<10;i++)al.add(i); new Thread(new Runnable() { @Overridepublic void run() {Iterator<Integer> it = al.iterator();while(it.hasNext()) {System.out.print(it.next()+" ");} }}).start(); new Thread(new Runnable() { @Overridepublic void run() {al.remove(6); } }).start();

?

如果拋出異常，就類似這個(gè)樣子：

0 1 Exception in thread "Thread-0" java.util.ConcurrentModificationExceptionat java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)at java.util.ArrayList$Itr.next(ArrayList.java:859)at com.rw.importword.utils.Text$1.run(Text.java:19)at java.lang.Thread.run(Thread.java:748)

?

但是也有可能不拋出異常：

?

根據(jù)輸出結(jié)果來(lái)看，al的結(jié)構(gòu)已經(jīng)改變，但是沒(méi)有拋出異常

至于原因我想是：

modCount沒(méi)有被voliate修飾，在線程之間不可見，可能某一個(gè)時(shí)機(jī)，線程2中remove操作改變的modCount值并沒(méi)有及時(shí)寫到內(nèi)存中，線程1中迭代器獲取的modCount值仍然是之前的值

?

由此可以得出，fail-fast機(jī)制，是一種錯(cuò)誤檢測(cè)機(jī)制。它只能被用來(lái)檢測(cè)錯(cuò)誤，因?yàn)镴DK并不保證fail-fast機(jī)制一定會(huì)發(fā)生。

?

轉(zhuǎn)載于:https://www.cnblogs.com/NextLight/p/9592069.html

總結(jié)

以上是生活随笔為你收集整理的通过ArrayList对modCount的操作分析fail-fast 机制的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。