Java中容器的迭代器的fail-fast机制

Iterator<Integer> keys = gradeMap.keySet().iterator();
        while(keys.hasNext()){
            Integer i = keys.next();
            if(!gradesIds.contains(i)){
//                keys.remove(); 
                gradeMap.remove(i);
            }
        }java

调用HashMap的reomve方法时会出现 java.util.ConcurrentModificationException 。网络

解决方法就是先用Iterator的方法remove,而后再调用HashMap的remove方法!!即代码以下:并发

Iterator<Integer> keys = gradeMap.keySet().iterator();
        while(keys.hasNext()){
            Integer i = keys.next();
            if(!gradesIds.contains(i)){
                keys.remove(); 
                gradeMap.remove(i);
            }
        }this

产生此问题的缘由spa

引用于网络:
       当使用 fail-fast iterator 对 Collection 或 Map 进行迭代操做过程当中尝试直接修改 Collection / Map 的内容时,即便是在单线程下运行, java.util.ConcurrentModificationException 异常也将被抛出。 

Iterator 是工做在一个独立的线程中,而且拥有一个 mutex 锁。 Iterator 被建立以后会创建一个指向原来对象的单链索引表,当原来的对象数量发生变化时,这个索引表的内容不会同步改变,因此当索引指针日后移动的时候就找不到要迭 代的对象,因此按照 fail-fast 原则 Iterator 会立刻抛出 java.util.ConcurrentModificationException 异常。 

因此 Iterator 在工做的时候是不容许被迭代的对象被改变的。但你可使用 Iterator 自己的方法 remove() 来删除对象, Iterator.remove() 方法会在删除当前迭代对象的同时维护索引的一致性。 

有意思的是若是你的 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. 

附:来自ibm developerworks上对java.util.concurrent包的说明片断: 
      java.util 包中的集合类都返回 fail-fast 迭代器,这意味着它们假设线程在集合内容中进行迭代时,集合不会更改它的内容。若是 fail-fast 迭代器检测到在迭代过程当中进行了更改操做,那么它会抛出 ConcurrentModificationException ,这是不可控异常。 
      在迭代过程当中不更改集合的要求一般会对许多并发应用程序形成不便。相反,比较好的是它容许并发修改并确保迭代器只要进行合理操做,就能够提供集合的一致视图,如 java.util.concurrent 集合类中的迭代器所作的那样。 
     java.util.concurrent 集合返回的迭代器称为弱一致的(weakly consistent) 迭代器。对于这些类,若是元素自从迭代开始已经删除,且还没有由 next() 方法返回,那么它将不返回到调用者。若是元素自迭代开始已经添加,那么它可能返回调用者,也可能不返回。在一次迭代中,不管如何更改底层集合,元素不会被 返回两次。线程

相关文章
相关标签/搜索