fail-fast究竟是个什么鬼? r囧r小猫 2021-10-19 15:52 354阅读 0赞 ### fail-fast ### * 概念引入 * 实例分析 * 集合类中的fail-fast * 异常分析 * 异常原理 * 总结 # 概念引入 # 首先我们看下维基百科中关于fail-fast的解释: 在系统设计中,快速失效系统一种可以立即报告任何可能表明故障的情况的系统。快速失效系统通常设计用于停止正常操作,而不是 试图继续可能存在缺陷的过程。这种设计通常会在操作中的多个点检查系统的状态,因此可以及早检测到任何故障。快速失败模块的职责是 检测错误,然后让系统的下一个最高级别处理错误。 其实,这是一种理念,fail-fast就是在做系统设计的时候先考虑异常情况,一旦发生异常,直接停止并上报。 # 实例分析 # 举一个最简单的fail-fast的例子: public int divide(int divisor,int dividend){ if(dividend == 0){ throw new RuntimeException("dividend can't be null"); } return divisor/dividend; } 上面的代码是对两个整数做除法的方法,在divide方法中,我们对被除数做了个简单的检查,如果其值为0,那么就直接抛出一个异常,并明确提示异常原因。这其实就是fail-fast理念的实际应用。 这样做的好处就是可以预先识别出一些错误情况,一方面可以避免执行复杂的其他代码,另外一方面,这种异常情况被识别之后也可以针对性的做一些单独处理。 怎么样,现在你知道fail-fast了吧,其实它并不神秘,你日常的代码中可能经常会在使用的。 既然,fail-fast是一种比较好的机制,那为什么说fail-fast会有坑呢? 原因是Java的部分集合类中运用了fail-fast机制进行设计,一旦使用不当,触发fail-fast机制设计的代码,就会发生非预期情况。 # 集合类中的fail-fast # 我们通常说的Java中的fail-fast机制,默认指的是Java集合的一种错误检测机制。当多个线程对部分集合进行结构上的改变的操作时,有可能会产生fail-fast机制,这个时候就会抛出ConcurrentModificationException。 ConcurrentModificationException,当方法检测到对象的并发修改,但不允许这种修改时就抛出该异常。 很多时候正是因为代码中抛出了ConcurrentModificationException,很多程序员就会很困惑,明明自己的代码并没有在多线程环境中执行,为什么会抛出这种并发有关的异常呢?这种情况在什么情况下才会抛出呢?我们就来深入分析一下。 # 异常分析 # 在Java中, 如果在增强for循环里对某些集合元素进行元素的 remove/add 操作的时候,就会触发fail-fast机制,进而抛出ConcurrentModificationException。 如以下代码: List<String> userNames = new ArrayList<String>() { { add("Jobs"); add("jobs"); add("JobsSteven"); add("J"); }}; for (String userName : userNames) { if (userName.equals("Jobs")) { userNames.remove(userName); } } System.out.println(userNames); 以上代码,使用增强for循环遍历元素,并尝试删除其中的Hollis字符串元素。运行以上代码,会抛出以下异常: Exception in thread "main" java.util.ConcurrentModificationException at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909) at java.util.ArrayList$Itr.next(ArrayList.java:859) at com.hollis.ForEach.main(ForEach.java:22) 同样的,读者可以尝试下在增强for循环中使用add方法添加元素,结果也会同样抛出该异常。 在深入原理之前,我们先尝试把foreach进行解语法糖,看一下foreach具体如何实现的。 我们使用jad工具,对编译后的class进行反编译,得到以下代码: public static void main(String[] args) { // 使用ImmutableList初始化一个List List<String> userNames = new ArrayList<String>() { { add("Jobs"); add("jobs"); add("JobsSteven"); add("J"); }}; Iterator iterator = userNames.iterator(); do { if(!iterator.hasNext()) break; String userName = (String)iterator.next(); if(userName.equals("Jobs")) userNames.remove(userName); } while(true); System.out.println(userNames); } 可以发现,foreach其实是依赖了while循环和Iterator实现的。 # 异常原理 # 通过以上代码的异常堆栈,我们可以跟踪到真正抛出异常的代码是: java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909) 该方法是在iterator.next()方法中调用的。我们看下该方法的实现: final void checkForComodification() { if (modCount != expectedModCount) throw new ConcurrentModificationException(); } 如上,在该方法中对modCount和expectedModCount进行了比较,如果二者不想等,则抛出ConcurrentModificationException。 那么,modCount和expectedModCount是什么?是什么原因导致他们的值不想等的呢? modCount是ArrayList中的一个成员变量。它表示该集合实际被修改的次数。 List<String> userNames = new ArrayList<String>() { { add("Jobs"); add("jobs"); add("JobsSteven"); add("J"); }}; 当使用以上代码初始化集合之后该变量就有了。初始值为0。 expectedModCount 是 ArrayList中的一个内部类——Itr中的成员变量。 Iterator iterator = userNames.iterator(); 以上代码,即可得到一个 Itr类,该类实现了Iterator接口。 expectedModCount表示这个迭代器预期该集合被修改的次数。其值随着Itr被创建而初始化。只有通过迭代器对集合进行操作,该值才会改变。 那么,接着我们看下userNames.remove(userName);方法里面做了什么事情,为什么会导致expectedModCount和modCount的值不一样。 通过翻阅代码,我们也可以发现,remove方法核心逻辑如下: private void fastRemove(int index) { modCount++; int numMoved = size - index - 1; if (numMoved > 0) System.arraycopy(elementData, index+1, elementData, index, numMoved); elementData[--size] = null; // clear to let GC do its work } 可以看到,remove方法只修改了modCount,并没有对expectedModCount做任何操作。 # 总结 # 简单总结一下,之所以会抛出ConcurrentModificationException异常,是因为我们的代码中使用了增强for循环,而在增强for循环中,集合遍历是通过Iterator进行的,但是元素的add/remove却是直接使用的集合类自己的方法。这就导致iterator在遍历的时候,会发现有一个元素在自己不知不觉的情况下就被删除/添加了,就会抛出一个异常,用来提示用户,可能发生了并发修改! 所以,在使用Java的集合类的时候,如果发生ConcurrentModificationException,优先考虑fail-fast有关的情况,实际上这里并没有真的发生并发,只是Iterator使用了fail-fast的保护机制,只要他发现有某一次修改是未经过自己进行的,那么就会抛出异常。
还没有评论,来说两句吧...