如Java中的容器Map：
for(Person person : pList){
if(person.getGender()==Gender.MALE){
pList.remove(person); //不能在遍歷期間進行 remove這個操作
}
}
Map在遍歷時候通常 現(xiàn)獲得其鍵值的集合Set，然后用迭代器Iterator來對Map進行遍歷。
注意在遍歷的過程中，只能對Map中的元素進行相應(yīng)的處理，不能把Map元素增加或者把Map元素減少，也就是說，不能改變Map的size大小，就會出現(xiàn)異常（不能在遍歷過程中修改刪除或者增加map中的元素）
報出的異常為 java.util.ConcurrentModificationException 異常
public class ConcurrentModificationExceptionextends RuntimeException
當(dāng)方法檢測到對象的并發(fā)修改，但不允許這種修改時，拋出此異常。
例如，某個線程在 Collection 上進行迭代時，通常不允許另一個線性修改該 Collection。通常在這些情況下，迭代的結(jié)果是不明確的。如果檢測到這種行為，一些迭代器實現(xiàn)（包括 JRE 提供的所有通用 collection 實現(xiàn)）可能選擇拋出此異常。執(zhí)行該操作的迭代器稱為快速失敗迭代器，因為迭代器很快就完全失敗，而不會冒著在將來某個時間任意發(fā)生不確定行為的風(fēng)險。
注意，此異常不會始終指出對象已經(jīng)由不同 線程并發(fā)修改。如果單線程發(fā)出違反對象協(xié)定的方法調(diào)用序列，則該對象可能拋出此異常。例如，如果線程使用快速失敗迭代器在 collection 上迭代時直接修改該 collection，則迭代器將拋出此異常。
注意，迭代器的快速失敗行為無法得到保證，因為一般來說，不可能對是否出現(xiàn)不同步并發(fā)修改做出任何硬性保證?？焖偈〔僮鲿M最大努力拋出 ConcurrentModificationException。因此，為提高此類操作的正確性而編寫一個依賴于此異常的程序是錯誤的做法，正確做法是：ConcurrentModificationException 應(yīng)該僅用于檢測 bug。
當(dāng)使用 fail-fast iterator 對 Collection 或 Map 進行迭代操作過程中嘗試直接修改 Collection / Map 的內(nèi)容時，即使是在單線程下運行， java.util.ConcurrentModificationException 異常也將被拋出。
　　Iterator 是工作在一個獨立的線程中，并且擁有一個 mutex 鎖。 Iterator 被創(chuàng)建之后會建立一個指向原來對象的單鏈索引表，當(dāng)原來的對象數(shù)量發(fā)生變化時，這個索引表的內(nèi)容不會同步改變，所以當(dāng)索引指針往后移動的時候就找不到要迭代的對象，所以按照 fail-fast 原則 Iterator 會馬上拋出 java.util.ConcurrentModificationException 異常。
　　所以 Iterator 在工作的時候是不允許被迭代的對象被改變的。但你可以使用 Iterator 本身的方法 remove() 來刪除對象， Iterator.remove() 方法會在刪除當(dāng)前迭代對象的同時維護索引的一致性。
　　有意思的是如果你的 Collection / Map 對象實際只有一個元素的時候， ConcurrentModificationException 異常并不會被拋出。這也就是為什么在 javadoc 里面指出： it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.

最新評論