什么是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
**
我们通常说的Java中的fail-fast机制，默认指的是Java集合的一种错误检测机制。当多个线程对部分集合进行结构上的改变的操作时，有可能会产生fail-fast机制，这个时候就会抛出ConcurrentModificationException（后文用CMException代替）。
CMException，当方法检测到对象的并发修改，但不允许这种修改时就抛出该异常。
很多时候正是因为代码中抛出了CMException，很多程序员就会很困惑，明明自己的代码并没有在多线程环境中执行，为什么会抛出这种并发有关的异常呢？这种情况在什么情况下才会抛出呢？我们就来深入分析一下。
异常复现
在Java中， 如果在foreach 循环里对某些集合元素进行元素的 remove/add 操作的时候，就会触发fail-fast机制，进而抛出CMException。
List<String> userNames = new ArrayList<String>() {{add("Hollis");add("hollis");add("HollisChuang");add("H");}};for (String userName : userNames) {if (userName.equals("Hollis")) {userNames.remove(userName);}}System.out.println(userNames);
以上代码，使用增强for循环遍历元素，并尝试删除其中的Hollis字符串元素。运行以上代码，会抛出以下异常：
Exception in thread "main" java.util.ConcurrentModificationExceptionat 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初始化一个ListList<String> userNames = new ArrayList<String>() {{add("Hollis");add("hollis");add("HollisChuang");add("H");}};Iterator iterator = userNames.iterator();do{if(!iterator.hasNext())break;String userName = (String)iterator.next();if(userName.equals("Hollis"))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进行了比较，如果二者不想等，则抛出CMException。
那么，modCount和expectedModCount是什么？是什么原因导致他们的值不想等的呢？
modCount是ArrayList中的一个成员变量。它表示该集合实际被修改(新增，修改，删除)的次数。
List<String> userNames = new ArrayList<String>() {{add("Hollis");add("hollis");add("HollisChuang");add("H");}};
当使用以上代码初始化集合之后该变量就有了。初始值为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做任何操作。
简单画一张图描述下以上场景：
简单总结一下，之所以会抛出CMException异常，是因为我们的代码中使用了增强for循环，而在增强for循环中，集合遍历是通过iterator进行的，但是元素的add/remove却是直接使用的集合类自己的方法。这就导致iterator在遍历的时候，会发现有一个元素在自己不知不觉的情况下就被删除/添加了，就会抛出一个异常，用来提示用户，可能发生了并发修改！
所以，在使用Java的集合类的时候，如果发生CMException，优先考虑fail-fast有关的情况，实际上这里并没有真的发生并发，只是Iterator使用了fail-fast的保护机制，只要他发现有某一次修改是未经过自己进行的，那么就会抛出异常。
在阿里巴巴Java开发手册中，有这样一条规定：
解决方法
直接使用普通for循环进行操作
我们说不能在foreach中进行，但是使用普通的for循环还是可以的，因为普通for循环并没有用到Iterator的遍历，所以压根就没有进行fail-fast的检验。
List<String> userNames = new ArrayList<String>() {{add("Hollis");add("hollis");add("HollisChuang");add("H");}};for (int i = 0; i < 1; i++) {if (userNames.get(i).equals("Hollis")) {userNames.remove(i);}}System.out.println(userNames);
直接使用Iterator进行操作
除了直接使用普通for循环以外，我们还可以直接使用Iterator提供的remove方法。
List<String> userNames = new ArrayList<String>() {{add("Hollis");add("hollis");add("HollisChuang");add("H");}};Iterator iterator = userNames.iterator();while (iterator.hasNext()) {if (iterator.next().equals("Hollis")) {iterator.remove();}}System.out.println(userNames);
如果直接使用Iterator提供的remove方法，那么就可以修改到expectedModCount的值。那么就不会再抛出异常了。其实现代码如下：
使用Java 8中提供的filter过滤
Java 8中可以把集合转换成流，对于流有一种filter操作， 可以对原始 Stream 进行某项测试，通过测试的元素被留下来生成一个新 Stream。
List<String> userNames = new ArrayList<String>() {{add("Hollis");add("hollis");add("HollisChuang");add("H");}};userNames = userNames.stream().filter(userName -> !userName.equals("Hollis")).collect(Collectors.toList());System.out.println(userNames);
直接使用fail-safe的集合类
在Java中，除了一些普通的集合类以外，还有一些采用了fail-safe机制的集合类。这样的集合容器在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。
由于迭代时是对原集合的拷贝进行遍历，所以在遍历过程中对原集合所作的修改并不能被迭代器检测到，所以不会触发ConcurrentModificationException。
ConcurrentLinkedDeque<String> userNames = new ConcurrentLinkedDeque<String>() {{add("Hollis");add("hollis");add("HollisChuang");add("H");}};for (String userName : userNames) {if (userName.equals("Hollis")) {userNames.remove();}}
基于拷贝内容的优点是避免了ConcurrentModificationException，但同样地，迭代器并不能访问到修改后的内容，即：迭代器遍历的是开始遍历那一刻拿到的集合拷贝，在遍历期间原集合发生的修改迭代器是不知道的。
java.util.concurrent包下的容器都是安全失败，可以在多线程下并发使用，并发修改。
使用增强for循环其实也可以
如果，我们非常确定在一个集合中，某个即将删除的元素只包含一个的话， 比如对Set进行操作，那么其实也是可以使用增强for循环的，只要在删除之后，立刻结束循环体，不要再继续进行遍历就可以了，也就是说不让代码执行到下一次的next方法。
**
List<String> userNames = new ArrayList<String>() {{add("Hollis");add("hollis");add("HollisChuang");add("H");}};for (String userName : userNames) {if (userName.equals("Hollis")) {userNames.remove(userName);break;}}System.out.println(userNames);
以上这五种方式都可以避免触发fail-fast机制，避免抛出异常。如果是并发场景，建议使用concurrent包中的容器，如果是单线程场景，Java8之前的代码中，建议使用Iterator进行元素删除，Java8及更新的版本中，可以考虑使用Stream及filter。
总结
我们使用的增强for循环，其实是Java提供的语法糖，其实现原理是借助Iterator进行元素的遍历。
但是如果在遍历过程中，不通过Iterator，而是通过集合类自身的方法对集合进行添加/删除操作。那么在Iterator进行下一次的遍历时，经检测发现有一次集合的修改操作并未通过自身进行，那么可能是发生了并发被其他线程执行的，这时候就会抛出异常，来提示用户可能发生了并发修改，这就是所谓的fail-fast机制。
当然还是有很多种方法可以解决这类问题的。比如使用普通for循环、使用Iterator进行元素删除、使用Stream的filter、使用fail-safe的类等。
若有收获，就点个赞吧
0 人点赞
