为什么阿里巴巴强制不要在 Foreach 里执行删除操作

为了镇楼,阿里先搬一段英文来解释一下 fail-fast。巴巴不

In systems design,强制 a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process. Such designs often check the systems state at several points in an operation, so any failures can be detected early. The responsibility of a fail-fast module is detecting errors, then letting the next-highest level of the system handle them.

这段话的大致意思就是,fail-fast 是行删一种通用的系统设计思想,一旦检测到可能会发生错误,除操就立马抛出异常,阿里程序将不再往下执行。巴巴不

public void test(Wanger wanger) {         if (wanger == null) {          throw new RuntimeException("wanger 不能为空");     }     System.out.println(wanger.toString()); } 

一旦检测到 wanger 为 null,强制就立马抛出异常,行删让调用者来决定这种情况下该怎么处理,除操下一步 wanger.toString() 就不会执行了——避免更严重的阿里错误出现。

很多时候,巴巴不我们会把 fail-fast 归类为 Java 集合框架的强制一种错误检测机制,但其实 fail-fast 并不是行删 Java 集合框架特有的机制。

之所以我们把 fail-fast 放在集合框架篇里介绍,除操是因为问题比较容易再现。

List<String> list = new ArrayList<>(); list.add("沉默王二"); list.add("沉默王三"); list.add("一个文章真特么有趣的程序员"); for (String str : list) {   if ("沉默王二".equals(str)) {    list.remove(str);  } } System.out.println(list); 

这段代码看起来没有任何问题,但运行起来就报错了。

根据错误的堆栈信息,我们可以定位到 ArrayList 的第 901 行代码。

final void checkForComodification() {      if (modCount != expectedModCount)         throw new ConcurrentModificationException(); } 

也就是说,源码库remove 的时候触发执行了 checkForComodification 方法,该方法对 modCount 和 expectedModCount 进行了比较,发现两者不等,就抛出了 ConcurrentModificationException 异常。

为什么会执行 checkForComodification 方法呢?

是因为 for-each 本质上是个语法糖,底层是通过迭代器 Iterator 配合 while 循环实现的,来看一下反编译后的字节码。

List<String> list = new ArrayList(); list.add("沉默王二"); list.add("沉默王三"); list.add("一个文章真特么有趣的程序员"); Iterator var2 = list.iterator(); while(var2.hasNext()) {      String str = (String)var2.next();     if ("沉默王二".equals(str)) {          list.remove(str);     } } System.out.println(list); 

来看一下 ArrayList 的 iterator 方法吧:

public Iterator<E> iterator() {      return new Itr(); } 

内部类 Itr 实现了 Iterator 接口。

private class Itr implements Iterator<E> {      int cursor;       // index of next element to return     int lastRet = -1; // index of last element returned; -1 if no such     int expectedModCount = modCount;     Itr() { }     public boolean hasNext() {          return cursor != size;     }     @SuppressWarnings("unchecked")     public E next() {          checkForComodification();         int i = cursor;         Object[] elementData = ArrayList.this.elementData;         if (i >= elementData.length)             throw new ConcurrentModificationException();         cursor = i + 1;         return (E) elementData[lastRet = i];     } } 

也就是说 new Itr() 的时候 expectedModCount 被赋值为 modCount,而 modCount 是 List 的一个成员变量,表示集合被修改的次数。由于 list 此前执行了 3 次 add 方法。

add 方法调用 ensureCapacityInternal 方法 ensureCapacityInternal 方法调用 ensureExplicitCapacity 方法 ensureExplicitCapacity 方法中会执行 modCount++

所以 modCount 的值在经过三次 add 后为 3,于是 new Itr() 后 expectedModCount 的值也为 3。

执行第一次循环时,发现“沉默王二”等于 str,于是云服务器提供商执行 list.remove(str)。

remove 方法调用 fastRemove 方法 fastRemove 方法中会执行 modCount++ 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 } 

modCount 的值变成了 4。

执行第二次循环时,会执行 Itr 的 next 方法(String str = (String) var3.next();),next 方法就会调用 checkForComodification 方法,此时 expectedModCount 为 3,modCount 为 4,就只好抛出 ConcurrentModificationException 异常了。

那其实在阿里巴巴的 Java 开发手册里也提到了,不要在 for-each 循环里进行元素的 remove/add 操作。remove 元素请使用 Iterator 方式。

那原因其实就是我们上面分析的这些,出于 fail-fast 保护机制。

那该如何正确地删除元素呢?

1)remove 后 break

List<String> list = new ArrayList<>(); list.add("沉默王二"); list.add("沉默王三"); list.add("一个文章真特么有趣的程序员"); for (String str : list) {   if ("沉默王二".equals(str)) {    list.remove(str);   break;  } } 

break 后循环就不再遍历了,意味着 Iterator 的 next 方法不再执行了,也就意味着 checkForComodification 方法不再执行了,所以异常也就不会抛出了。

但是呢,当 List 中有重复元素要删除的时候,break 就不合适了。

2)for 循环

List<String> list = new ArrayList<>(); list.add("沉默王二"); list.add("沉默王三"); list.add("一个文章真特么有趣的程序员"); for (int i = 0, n = list.size(); i < n; i++) {   String str = list.get(i);  if ("沉默王二".equals(str)) {    list.remove(str);  } } 

for 循环虽然可以避开 fail-fast 保护机制,也就说 remove 元素后不再抛出异常;但是站群服务器呢,这段程序在原则上是有问题的。为什么呢?

第一次循环的时候,i 为 0,list.size() 为 3,当执行完 remove 方法后,i 为 1,list.size() 却变成了 2,因为 list 的大小在 remove 后发生了变化,也就意味着“沉默王三”这个元素被跳过了。能明白吗?

remove 之前 list.get(1) 为“沉默王三”;但 remove 之后 list.get(1) 变成了“一个文章真特么有趣的程序员”,而 list.get(0) 变成了“沉默王三”。

3)使用 Iterator

List<String> list = new ArrayList<>(); list.add("沉默王二"); list.add("沉默王三"); list.add("一个文章真特么有趣的程序员"); Iterator<String> itr = list.iterator(); while (itr.hasNext()) {   String str = itr.next();  if ("沉默王二".equals(str)) {    itr.remove();  } } 

为什么使用 Iterator 的 remove 方法就可以避开 fail-fast 保护机制呢?看一下 remove 的源码就明白了。

public void remove() {      if (lastRet < 0)         throw new IllegalStateException();     checkForComodification();     try {          ArrayList.this.remove(lastRet);         cursor = lastRet;         lastRet = -1;         expectedModCount = modCount;     } catch (IndexOutOfBoundsException ex) {          throw new ConcurrentModificationException();     } } 

删除完会执行 expectedModCount = modCount,保证了 expectedModCount 与 modCount 的同步。

简单地总结一下,fail-fast 是一种保护机制,可以通过 for-each 循环删除集合的元素的方式验证这种保护机制。 

那也就是说,for-each 本质上是一种语法糖,遍历集合时很方面,但并不适合拿来操作集合中的元素(增删)。

本文转载自微信公众号「沉默王二」,可以通过以下二维码关注。转载本文请联系沉默王二公众号。

IT科技
上一篇:如何让数据中心运维工作更加高效可靠?
下一篇:刘新民:向数据更靠近,向底层更深入