zoukankan      html  css  js  c++  java
  • 为什么禁止在 foreach 循环里进行元素的 remove/add 操作

      首先看下边一个例子,展示了正确的做法和错误的错发:

      这是为什么呢,具体原因下面进行详细说明:

    1、foreach循环(Foreach loop)是计算机编程语言中的一种控制流程语句,通常用来循环遍历数组或集合中的元素。Java语言从JDK 1.5.0开始引入foreach循环。在遍历数组、集合方面,foreach为开发人员提供了极大的方便。通常也被称之为增强for循环。其实,增强for循环也是Java给我们提供的一个语法糖,如果将以上代码编译后的class文件进行反编译(使用jad工具)的话,可以得到以下代码:

     1 Iterator iterator = userNames.iterator();
     2 do
     3 {
     4     if(!iterator.hasNext())
     5         break;
     6     String userName = (String)iterator.next();
     7     if(userName.equals("Hollis"))
     8         userNames.remove(userName);
     9 } while(true);
    10 System.out.println(userNames);

      可以发现,原本的增强for循环,其实是依赖了while循环和Iterator实现的。

      那么,我们再看下,如果使用增强for循环的话会发生什么:

     1 List<String> userNames = new ArrayList<String>() {{
     2     add("Hollis");
     3     add("hollis");
     4     add("HollisChuang");
     5     add("H");
     6 }};
     7 
     8 for (String userName : userNames) {
     9     if (userName.equals("Hollis")) {
    10         userNames.remove(userName);
    11     }
    12 }
    13 
    14 System.out.println(userNames);

      以上代码,使用增强for循环遍历元素,并尝试删除其中的Hollis字符串元素。运行以上代码,会抛出以下异常:

    1 java.util.ConcurrentModificationException

      之所以会出现这个异常,是因为触发了一个Java集合的错误检测机制——fail-fast

    2、接下来,我们就来分析下在增强for循环中add/remove元素的时候会抛出java.util.ConcurrentModificationException的原因,即解释下到底什么是fail-fast进制,fail-fast的原理等。

      fail-fast,即快速失败,它是Java集合的一种错误检测机制。当多个线程对集合(非fail-safe的集合类)进行结构上的改变的操作时,有可能会产生fail-fast机制,这个时候就会抛出ConcurrentModificationException(当方法检测到对象的并发修改,但不允许这种修改时就抛出该异常)。

      同时需要注意的是,即使不是多线程环境,如果单线程违反了规则,同样也有可能会抛出改异常。

      那么,在增强for循环进行元素删除,是如何违反了规则的呢?

      (1)Iterator.next 调用了 Iterator.checkForComodification方法 ,而异常就是checkForComodification方法中抛出的。

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

      (2)modCount是ArrayList中的一个成员变量。它表示该集合实际被修改的次数,remove方法它只修改了modCount,并没有对expectedModCount做任何操作,所以导致抛出java.util.ConcurrentModificationException异常

      简单总结一下,之所以会抛出ConcurrentModificationException异常,是因为我们的代码中使用了增强for循环,而在增强for循环中,集合遍历是通过iterator进行的,但是元素的add/remove却是直接使用的集合类自己的方法。这就导致iterator在遍历的时候,会发现有一个元素在自己不知不觉的情况下就被删除/添加了,就会抛出一个异常,用来提示用户,可能发生了并发修改。

    3、正确姿势

      1、直接使用普通for循环进行操作

        我们说不能在foreach中进行,但是使用普通的for循环还是可以的,因为普通for循环并没有用到Iterator的遍历,所以压根就没有进行fail-fast的检验  

     1    List<String> userNames = new ArrayList<String>() {{
     2         add("Hollis");
     3         add("hollis");
     4         add("HollisChuang");
     5         add("H");
     6     }};
     7 
     8     for (int i = 0; i < 1; i++) {
     9         if (userNames.get(i).equals("Hollis")) {
    10             userNames.remove(i);
    11         }
    12     }
    13     System.out.println(userNames);

      2、直接使用Iterator进行操作

        除了直接使用普通for循环以外,我们还可以直接使用Iterator提供的remove方法,如果直接使用Iterator提供的remove方法,那么就可以修改到expectedModCount的值。那么就不会再抛出异常了。其实现代码如下:

     1     List<String> userNames = new ArrayList<String>() {{
     2         add("Hollis");
     3         add("hollis");
     4         add("HollisChuang");
     5         add("H");
     6     }};
     7 
     8     Iterator iterator = userNames.iterator();
     9 
    10     while (iterator.hasNext()) {
    11         if (iterator.next().equals("Hollis")) {
    12             iterator.remove();
    13         }
    14     }
    15     System.out.println(userNames);

      3、使用Java 8中提供的filter过滤

        Java 8中可以把集合转换成流,对于流有一种filter操作, 可以对原始 Stream 进行某项测试,通过测试的元素被留下来生成一个新 Stream。

    1     List<String> userNames = new ArrayList<String>() {{
    2         add("Hollis");
    3         add("hollis");
    4         add("HollisChuang");
    5         add("H");
    6     }};
    7 
    8     userNames = userNames.stream().filter(userName -> !userName.equals("Hollis")).collect(Collectors.toList());
    9     System.out.println(userNames);

      4、直接使用fail-safe的集合类

        在Java中,除了一些普通的集合类以外,还有一些采用了fail-safe机制的集合类。这样的集合容器在遍历时不是直接在集合内容上访问的,而是先复制原有集合内容,在拷贝的集合上进行遍历。

        由于迭代时是对原集合的拷贝进行遍历,所以在遍历过程中对原集合所作的修改并不能被迭代器检测到,所以不会触发ConcurrentModificationException。 

     1 ConcurrentLinkedDeque<String> userNames = new ConcurrentLinkedDeque<String>() {{
     2     add("Hollis");
     3     add("hollis");
     4     add("HollisChuang");
     5     add("H");
     6 }};
     7 
     8 for (String userName : userNames) {
     9     if (userName.equals("Hollis")) {
    10         userNames.remove();
    11     }
    12 }    

        基于拷贝内容的优点是避免了ConcurrentModificationException,但同样地,迭代器并不能访问到修改后的内容,即:迭代器遍历的是开始遍历那一刻拿到的集合拷贝,在遍历期间原集合发生的修改迭代器是不知道的。

        java.util.concurrent包下的容器都是安全失败,可以在多线程下并发使用,并发修改。

      5、使用增强for循环其实也可以

        如果,我们非常确定在一个集合中,某个即将删除的元素只包含一个的话, 比如对Set进行操作,那么其实也是可以使用增强for循环的,只要在删除之后,立刻结束循环体,不要再继续进行遍历就可以了,也就是说不让代码执行到下一次的next方法

     1     List<String> userNames = new ArrayList<String>() {{
     2         add("Hollis");
     3         add("hollis");
     4         add("HollisChuang");
     5         add("H");
     6     }};
     7 
     8     for (String userName : userNames) {
     9         if (userName.equals("Hollis")) {
    10             userNames.remove(userName);
    11             break;
    12         }
    13     }
    14     System.out.println(userNames);

        以上这五种方式都可以避免触发fail-fast机制,避免抛出异常。如果是并发场景,建议使用concurrent包中的容器,如果是单线程场景,Java8之前的代码中,建议使用Iterator进行元素删除,Java8及更新的版本中,可以考虑使用Stream及filter。

    原文链接:https://mp.weixin.qq.com/s/zI0AnGYhkojNl4qVJZaCBQ

  • 相关阅读:
    阶段一-01.万丈高楼,地基首要-第2章 单体架构设计与准备工作-2-17 MyBatis 数据库逆向生成工具
    阶段一-01.万丈高楼,地基首要-第2章 单体架构设计与准备工作-2-16 数据源连接数详解
    阶段一-01.万丈高楼,地基首要-第2章 单体架构设计与准备工作-2-14 数据层HikariCP与MyBatis整合
    阶段一-01.万丈高楼,地基首要-第2章 单体架构设计与准备工作-2-13 HikariCP数据源简述
    阶段一-01.万丈高楼,地基首要-第2章 单体架构设计与准备工作-2-12 SpringBoot自动装配简述
    阶段一-01.万丈高楼,地基首要-第2章 单体架构设计与准备工作-2-10 聚合工程整合SpringBoot
    阶段一-01.万丈高楼,地基首要-第2章 单体架构设计与准备工作-2-9 数据库物理外键移除原因讲解
    阶段一-01.万丈高楼,地基首要-第2章 单体架构设计与准备工作-2-8 生产环境增量与全量脚本迭代讲解
    阶段一-01.万丈高楼,地基首要-第2章 单体架构设计与准备工作-2-7 PDMan数据库建模工具使用
    阶段一-01.万丈高楼,地基首要-第2章 单体架构设计与准备工作-2-6 构建聚合工程-2
  • 原文地址:https://www.cnblogs.com/nfex/p/10509720.html
Copyright © 2011-2022 走看看