解析Java的迭代器中的fast-fail错误检测机制

fail-fast 机制是java集合(Collection)中的一种错误机制。当多个线程对同一个集合的内容进行操作时,就可能会产生fail-fast事件。例如:当某一个线程A通过iterator去遍历某集合的过程中,若该集合的内容被其他线程所改变了;那么线程A访问集合时,就会抛出ConcurrentModificationException异常,产生fail-fast事件。
fail-fast 机制是java集合(Collection)中的一种错误机制。当多个线程对同一个集合的内容进行操作时,就可能会产生fail-fast事件。
例如:当某一个线程A通过iterator去遍历某集合的过程中,若该集合的内容被其他线程所改变了;那么线程A访问集合时,就会抛出ConcurrentModificationException异常,产生fail-fast事件。
要了解fail-fast机制,我们首先要对ConcurrentModificationException 异常有所了解。当方法检测到对象的并发修改,但不允许这种修改时就抛出该异常。同时需要注意的是,该异常不会始终指出对象已经由不同线程并发修改,如果单线程违反了规则,同样也有可能会抛出改异常。
诚然,迭代器的快速失败行为无法得到保证,它不能保证一定会出现该错误,但是快速失败操作会尽最大努力抛出ConcurrentModificationException异常,所以因此,为提高此类操作的正确性而编写一个依赖于此异常的程序是错误的做法,正确做法是:ConcurrentModificationException 应该仅用于检测 bug。

Java中的Iterator非常方便地为所有的数据源提供了一个统一的数据读取(删除)的接口,但是新手通常在使用的时候容易报如下错误ConcurrentModificationException,原因是在使用迭代器时候底层数据被修改,最常见于数据源不是线程安全的类,如HashMap & ArrayList等。

为什么要有fast-fail
一个案例
来一个新手容易犯错的例子:

String[] stringArray = {"a","b","c","d"}; List<String> strings = Arrays.asList(stringArray); Iterator<String> iterator = strings.iterator(); while (iterator.hasNext()) { if(iterator.next().equals("c")) { strings.remove("c"); } }

更加常见的是在foreach(本质一样,都是调用Iterator时,操作了原始的strings)语句中:

for(String s : strings) { if(s.equals("c")) { strings.remove("c"); } }

产生原因
Java中的集合类(数据源)分为两种类型:线程安全,位于java.util.concurrent命名目录下,如CopyOnWriteArrayList;线程不安全:位于java.util目录下,如ArrayList,HashMap。所谓线程安全是在多线程环境下,这个类还能表现出和行为规范一致的结果,是否文绉绉的...自己google吧。

那既然我们可以有线程安全的集合替代品,那么为什么还要存在ArrayList等呢?因为线程安全的类通常需要通过各种手段去保持对数据访问的同步,所以通常来说效率会比较差。而如果使用者清楚自身使用场景不存在并发的场景,那么使用非线程安全的集合类在速度上有很大的优势。

如果开发者在使用时没有注意,将非线程安全的集合类用在了并发的场景下,比如线程A获取了ArrayList的iterator,然后线程B通过调用ArrayList.add()修改了ArrayList的数据,此时就有可能会抛出ConcurrentModificationException,注意,这里是有可能。那为啥上面的例子里面也会报这个错误呢?上面并不存在并发的情况,搂一眼源码吧。

Iterator源码分析
集合类中的fast-fail实现方式都差不多,我们以最简单的ArrayList为例吧。
ArrayList中会持有一个变量,声明为:
protected transient int modCount = 0;记录的是我们对ArrayList修改的次数,比如我们调用 add(),remove()等改变数据的操作时,会将modCount++。

我们通过ArrayList.iterator()返回的是一个实现了Iterator接口的ArrayListIterator:

private class ArrayListIterator implements Iterator<E> { //省略部分代码....... //初始化时,直接给expectedModCount赋ArrayList的修改次数 private int expectedModCount = modCount; @SuppressWarnings("unchecked") public E next() { ............ ArrayList<E> ourList = ArrayList.this; //简单比较一下当前iterator初始化时ArrayList.modCount的值 //和现在的值是否一致,如果不相等,认为在获取了当前iterator之后 //有别的位置(有可能是别的线程)修改了ArrayList,直接抛异常 if (ourList.modCount != expectedModCount) { throw new ConcurrentModificationException(); } ............ } }

原理很简单,构建Iterator时将当前ArrayList的modCount存起来,以后每一次next()时,判断ArrayList的modCount值是否有变化,如果有,则是在这个过程中有代码改变了数据(前面已经提及,只有调用add() remove()等才会去修改modCount的值)。
这也说明了为什么在例子里面我们并不是并发的场景也报错,因为我们调用ArrayList.remove()时改变了modCount的值。

但是这个东西意义有多大呢?在我看来它有点画蛇添足的嫌疑。因为在真正的并发场景下,这个fast-fail机制并不能真正即使发现另外线程访问并修改ArrayList中的数据。原因如下:

再看看modCount的定义protected transient int modCount = 0;。你没有看错,它就是一个普通的变量,那么在并发场景下由于共享对象的不可见性,有可能别的线程修改了ArrayList中的modCount,而iterator所在的线程却并没有读取到这个更新。HashMap在1.6以前确实是用了volatile来修饰了modCount来保证各个线程直接对modCount的可见性,但是在1.7里面把这个修饰去掉了,而且认为这是一个bug-->Java7去掉volatitle,可悲啊。。。原因嘛,就是JDK的开发者认为为了这么个破事而需要使用volatitle简直浪费效率。

就算是使用volatitle就完事大吉了吗?nono,举个最简单的例子,线程A获取了一个集合类的Iterator,线程B调用了集合类的add(),在add()还没有执行到modCount++时,线程A获取执行,并执行结束。在这种场景下,执行结果并不确定。对于ArrayList的Iterator来说,有可能会报一个数组越界的异常...

总结
fast-fail是JDK为了提示开发者将非线程安全的类使用到并发的场景下时,抛出一个异常,及早发现代码中的问题。但正如本文前面所述,这种机制却不能绝对正确地给出提示,而且老的JDK版本为了更好地支持这个机制还付出了一定的效率代价。

fast-fail存在的唯一价值可能就是给新手制造一些迷惑,给他深入探索的动力...嘿嘿

补充:

很多网上资料说在使用Iterator时是不能修改数据的,这样也并不完全准确。即便是支持fast-fail的Iterator本身也提供了remove()来删除当前遍历到的元素,例如:ArrayListIterator中的remove(),前面举的栗子改成如下即可:

while (iterator.hasNext()) { if(iterator.next().equals("c")) { iterator.remove("c"); } }

时间: 2024-09-16 00:02:21

解析Java的迭代器中的fast-fail错误检测机制的相关文章

解析Java的迭代器中的fast-fail错误检测机制_Android

fail-fast 机制是java集合(Collection)中的一种错误机制.当多个线程对同一个集合的内容进行操作时,就可能会产生fail-fast事件.例如:当某一个线程A通过iterator去遍历某集合的过程中,若该集合的内容被其他线程所改变了:那么线程A访问集合时,就会抛出ConcurrentModificationException异常,产生fail-fast事件. fail-fast 机制是java集合(Collection)中的一种错误机制.当多个线程对同一个集合的内容进行操作时,

深入解析Java并发程序中线程的同步与线程锁的使用_java

synchronized关键字 synchronized,我们谓之锁,主要用来给方法.代码块加锁.当某个方法或者代码块使用synchronized时,那么在同一时刻至多仅有有一个线程在执行该段代码.当有多个线程访问同一对象的加锁方法/代码块时,同一时间只有一个线程在执行,其余线程必须要等待当前线程执行完之后才能执行该代码段.但是,其余线程是可以访问该对象中的非加锁代码块的. synchronized主要包括两种方法:synchronized 方法.synchronized 块. synchron

解析Java设计模式编程中命令模式的使用_java

定义:将一个请求封装成一个对象,从而让你使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢复功能.类型:行为类模式类图: 命令模式的结构        顾名思义,命令模式就是对命令的封装,首先来看一下命令模式类图中的基本结构: Command类:是一个抽象类,类中对需要执行的命令进行声明,一般来说要对外公布一个execute方法用来执行命令. ConcreteCommand类:Command类的实现类,对抽象类中声明的方法进行实现. Client类:最终的客户端调用

深入解析Java设计模式编程中观察者模式的运用_java

定义:定义对象间一种一对多的依赖关系,使得当每一个对象改变状态,则所有依赖于它的对象都会得到通知并自动更新.类型:行为类模式类图: 在软件系统中经常会有这样的需求:如果一个对象的状态发生改变,某些与它相关的对象也要随之做出相应的变化.比如,我们要设计一个右键菜单的功能,只要在软件的有效区域内点击鼠标右键,就会弹出一个菜单:再比如,我们要设计一个自动部署的功能,就像eclipse开发时,只要修改了文件,eclipse就会自动将修改的文件部署到服务器中.这两个功能有一个相似的地方,那就是一个对象要时

实例解析Java设计模式编程中的适配器模式使用_java

平时我们会经常碰到这样的情况,有了两个现成的类,它们之间没有什么联系,但是我们现在既想用其中一个类的方法,同时也想用另外一个类的方法.有一个解决方法是,修改它们各自的接口,但是这是我们最不愿意看到的.这个时候Adapter模式就会派上用场了. Adapter模式也叫适配器模式,是由GoF提出的23种设计模式的一种.Adapter模式是构造型模式之一,通过Adapter模式,可以改变已有类(或外部类)的接口形式. 适配器 模式 有三种方式,一种是对象适配器,一种是类适配器, 一种是接口适配器以下举

解析Java线程编程中的线程安全与synchronized的使用_java

一.什么时候会出现线程安全问题? 在单线程中不会出现线程安全问题,而在多线程编程中,有可能会出现同时访问同一个资源的情况,这种资源可以是各种类型的的资源:一个变量.一个对象.一个文件.一个数据库表等,而当多个线程同时访问同一个资源的时候,就会存在一个问题: 由于每个线程执行的过程是不可控的,所以很可能导致最终的结果与实际上的愿望相违背或者直接导致程序出错. 举个简单的例子: 现在有两个线程分别从网络上读取数据,然后插入一张数据库表中,要求不能插入重复的数据. 那么必然在插入数据的过程中存在两个操

解析Java和Eclipse中加载本地库(.dll文件)的详细说明_java

最近在做的工作要用到本地方法,需要在Java中加载不少动态链接库(以下为方便延用Windows平台下的简写dll,但并不局限于Windows).刚刚把程序跑通,赶紧把一些心得写出来,mark.也希望对大家的类似工作有所帮助首先,应当明确,dll有两类:(1)Java所依赖的dll和,(2)dll所依赖的dll.正是由于第(2)种dll的存在,才导致了java中加载dll的复杂性大大增加,许多说法都是这样的,但我实验的结果却表明似乎没有那么复杂,后面会予以详细阐述.其次,Java中加载dll的方式

实例解析Java单例模式编程中对抽象工厂模式的运用_java

定义:为创建一组相关或相互依赖的对象提供一个接口,而且无需指定他们的具体类. 类型:创建类模式 类图: 抽象工厂模式与工厂方法模式的区别        抽象工厂模式是工厂方法模式的升级版本,他用来创建一组相关或者相互依赖的对象.他与工厂方法模式的区别就在于,工厂方法模式针对的是一个产品等级结构:而抽象工厂模式则是针对的多个产品等级结构.在编程中,通常一个产品结构,表现为一个接口或者抽象类,也就是说,工厂方法模式提供的所有产品都是衍生自同一个接口或抽象类,而抽象工厂模式所提供的产品则是衍生自不同的

举例解析Java多线程编程中需要注意的一些关键点_java

1. 同步方法或同步代码块?您可能偶尔会思考是否要同步化这个方法调用,还是只同步化该方法的线程安全子集.在这些情况下,知道 Java 编译器何时将源代码转化为字节代码会很有用,它处理同步方法和同步代码块的方式完全不同. 当 JVM 执行一个同步方法时,执行中的线程识别该方法的 method_info 结构是否有 ACC_SYNCHRONIZED 标记设置,然后它自动获取对象的锁,调用方法,最后释放锁.如果有异常发生,线程自动释放锁. 另一方面,同步化一个方法块会越过 JVM 对获取对象锁和异常处