什么是fail-fast机制
fail-fast是一种错误检测机制，一般意义上的fail-fast是当我们的代码可能出现异常情况时，会立即抛出异常并中断执行，而不是继续执行。相反就是fail-safe机制。
在java中的fail-fast机制通常是指在集合中使用迭代器遍历时，当多个线程对同一集合进行操作时，就可能会产生fail-fast。比如当一个线程A通过迭代器正在遍历集合时，另一个线程又对该集合中的内容进行了修改，那么线程A在访问集合时，就会抛出ConcurrentModificationException异常，产生fail-fast机制。而采用fail-safe机制的集合在遍历时任何对集合内容的修改都会先复制一份原来，在复制的集合上进行修改，不影响原来的，所以不会抛出ConcurrentModificationException
在java中，线程不安全的集合类的迭代器实现一般都是fail-fast的，如HashMap，ArrayList等，而线程安全的集合是fail-safe的，如CopyOnWriteArrayList，ConcurrentHashMap
fail-fast实现机制
在java中，fail-fast是如何实现的呢？比如在ArrayList等集合中，都会维护一个modCount变量，当对集合进行增删等操作时，就会将modCount值加1。在迭代器中，会有一个expectedModCount，初始化设为modCount的值，在使用迭代器调用next，remove等方法时，会先调用函数checkForComodification()检查这两个值是否相等，不相等就抛出ConcurrentModificationException异常。
后续当一个线程在使用迭代器进行遍历时，另一个线程如果对集合做了修改，则会使modCount的值和expectedModCount的值不相等，则会抛出ConcurrentModificationException异常，导致fail-fast.
源码如下：
CopyOnWriteArrayList解决fail-fast
CopyOnWriteArrayList是juc包下的一个线程安全的集合，在需要同步的ArrayList时，可采用CopyOnWriteArrayList来替换Vector。使用CopyOnWriteArrayList集合进行遍历时不会产生fail-fast，即其是fail-safe的，其基本思想是每次对集合进行修改时都会拷贝一份原数组的副本，在拷贝的数组上进行修改，然后将原数组的指针指向拷贝后的。所以在当一个线程A对集合遍历时，另一个线程修改了集合，但线程A不会看到修改后的内容，迭代器遍历时是在原数组上遍历，所以不会发生fail-fast。
对比ArrayList和CopyOnWriteArrayList的源码：
可以看到CopyOnWriteArrayList中进行增删等修改操作时，都是先复制一份原来的数组，然后对复制的数组修改后再将原数组的指针指向复制的数组setArray
查看CopyOnWriteArrayList迭代器源码：
总结
Copy-On-Write是一种延时懒惰策略的思想，是写时复制的容器。CopyOnWriteArrayList中add/remove等写方法是需要加锁的，目的是为了避免Copy出N个副本出来，导致并发写。但是，CopyOnWriteArrayList中的读方法是没有加锁的。所以可以进行并发读，但是读到的数据可能不是最新的。所以CopyOnWrite容器是一种读写分离的思想，读和写不同的容器。而Vector在读写的时候使用同一个容器，读写互斥，同时只能做一件事儿。
subList中的fail-fast
什么是subList
subList是ArrayList中的一个方法，用来返回子列表，返回的子列表其实是原列表的视图。使用方式如下：1
2
3
4
5
6
7
8
9
10
11
12
13List<Integer> master = new ArrayList<>();
master.add(1);
master.add(2);
//子列表
List<Integer> sub = master.subList(0, master.size());
//复制列表
List<Integer> copy = new ArrayList<>(master);
//修改子列表
sub.add(3);
System.out.println("master == sub: " + master.equals(sub));
System.out.println("master == copy: " + master.equals(copy));
输出：1
2master == sub: true
master == copy: false
说明subList方法返回的是原来列表的一个视图，对子列表的修改其实是在原列表上进行修改。而通过构造函数复制的列表则是新建了一个列表对象。
查看源码，看subList如何创建的：
this直接把原列表引用传递进去了。subList为ArrayList的一个内部类。
parent即为传递进来的this，同时记录偏移量，计算size，以及将原列表的modCount复制过来。
我们再来看下subList的add，get等方法。
可以看到都是在原列表上进行修改的（只不过加了offset偏移量表示子列表的开始处）。注意上述为什么是ArrayList.this而不是this，因为是在subList内部类中访问外部类ArrayList的成员变量。
综上，所以对子列表的修改也会导致原列表发生变化。
为什么会发生fail-fast
如果我们对原列表进行修改后，然后再访问子列表，则访问子列表的代码就会发生ConcurrentModificationException异常。1
2
3
4
5
6
7
8
9
10
11List<Integer> master = new ArrayList<>();
master.add(1);
master.add(2);
//子列表
List<Integer> sub = master.subList(0, master.size());
//修改原列表
master.add(3);
System.out.println("master size: " + master.size());
System.out.println("sub size: " + sub.size());
输出：1
2
3
4
5master size: 3
Exception in thread "main" java.util.ConcurrentModificationException
at java.util.ArrayList$SubList.checkForComodification(ArrayList.java:1231)
at java.util.ArrayList$SubList.size(ArrayList.java:1040)
at com.xinyue.App.main(App.java:24)
对原列表修改后，访问子列表时抛出了ConcurrentModificationException异常，即发生了fail-fast机制。为什么会这样呢？
我们调用了子列表的size方法：
不管是size方法，还是之前的get，add等方法，都会调用checkForComodification函数检查是否修改。
所以很明显了，我们对子列表的修改其实是对原列表的修改，所以会导致原列表的modCount发生变化，而子列表的modCount是在一开始创建的时候就已经复制过来的，这时与原列表的不相等了，所以抛出异常，也就是我们所说的fail-fast检测。
参考：
