JAVA中简单的for循环竟有这么多坑，你踩过吗

悠悠 2023-10-01 22:32 31阅读 0赞

实际的业务项目开发中，大家应该对 `从给定的list中剔除不满足条件的元素` 这个操作不陌生吧？

很多同学可以立刻想出很多种实现的方式，但你想到的这些实现方式都是 `人畜无害` 的吗？很多看似正常的操作其实背后是个陷阱，很多新手可能稍不留神就会掉入其中。

倘若不幸踩中：

*  代码运行时直接抛异常报错，这个算是不幸中的万幸，至少可以及时发现并去解决
 *  代码运行不报错，但是业务逻辑莫名其妙的出现各种奇怪问题，这种就比较悲剧了，因为这个问题稍不留神的话，可能就会给后续业务埋下隐患。

![f0fb8166e8f77ca4c3e77e3a2928c63d.gif][]

那么，到底有哪些实现方式呢？哪些实现方式可能会存在问题呢？这里我们一起探讨下。注意哦，这里讨论的可不是茴香豆的“茴”字有有种写法的问题，而是很严肃很现实也很容易被忽略的技术问题。

假设需求场景：

给定一个用户列表allUsers，需要从该列表中剔除隶属部门为dev的人员，将剩余的人员信息返回

### 踩坑操作 ###

#### foreach循环剔除方式 ####

很多新手的第一想法就是for循环逐个判断校验下然后符合条件的剔除掉就行了嘛~ so easy...

1分钟就把代码写完了：

public List<UserDetail> filterAllDevDeptUsers(List<UserDetail> allUsers) {
        for (UserDetail user : allUsers) {
            // 判断部门如果属于dev,则直接剔除
            if ("dev".equals(user.getDepartment())) {
                allUsers.remove(user);
            }
        }
        // 返回剩余的用户数据
        return allUsers;
    }

然后信心满满的点击了执行按钮：

java.util.ConcurrentModificationException: null
    	at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
    	at java.util.ArrayList$Itr.next(ArrayList.java:859)
    	at com.veezean.demo4.UserService.filterAllDevDeptUsers(UserService.java:13)
    	at com.veezean.demo4.Main.main(Main.java:26)

诶？ what are you 弄啥嘞？咋抛异常了？

![95888a47a76c98efbd44427c5d2d072c.gif][]

一不留神就踩坑里了，下面就一起分析下为啥会抛异常。

原因分析：

JAVA的foreach语法实际处理是基于迭代器Iterator进行实现的。

在循环开始时，会首先创建一个迭代实例，这个迭代实例的 `expectedModCount` 赋值为集合的 `modCount` 。而每当迭代器使⽤ `hashNext()` / `next()` 遍历下⼀个元素之前，都会检测 `modCount` 变量与 `expectedModCount` 值是否相等，相等的话就返回遍历；否则就抛出异常 `ConcurrentModificationException` ，终⽌遍历。

如果在循环中添加或删除元素，是直接调用集合的 `add()` ， `remove()` 方法，导致了 `modCount` 增加或减少，但这些方法不会修改迭代实例中的 `expectedModCount` ，导致在迭代实例中 `expectedModCount` 与 `modCount` 的值不相等，抛出ConcurrentModificationException异常。

![fb9454b62a82433d0f6aba8b085b95f3.png][]

![43aff1043126b3a3bc3a3a1e28c1b839.gif][]

#### 下标循环操作 ####

嗯哼？既然foreach方式不行，那就用原始的下标循环的方式来搞，总不会报错了吧？依旧很easy ...

public List<UserDetail> filterAllDevDeptUsers(List<UserDetail> allUsers) {
        for (int i = 0; i < allUsers.size(); i++) {
            // 判断部门如果属于dev,则直接剔除
            if ("dev".equals(allUsers.get(i).getDepartment())) {
                allUsers.remove(i);
            }
        }
        // 返回剩余的用户数据
        return allUsers;
    }

代码一气呵成，执行一下，看下处理后的输出：

{id=2, name='李四', department='dev'}
    {id=3, name='王五', department='product'}
    {id=4, name='铁柱', department='pm'}

果然，不报错了，结果也输出了，完美~

等等？这样真的OK了吗？我们的代码逻辑里面是判断如果 `"dev".equals(department)` ，但是输出结果里面，为啥还是有 `department=dev` 这种本应被剔除掉的数据呢？

这里如果是在真实业务项目中，开发阶段不报错，又没有仔细去验证结果的情况下，流到生产线上，就可能造成业务逻辑的异常。

![af21ebc60fac18bd7a568e2d32ae7681.gif][]

接下来看下出现这个现象的具体原因。

原因分析：

我们知道，list中的元素与下标之间，其实并没有强绑定关系，仅仅只是一个位置顺序的对应关系，list中元素变更之后，其每个元素对应的下标都可能会变更，如下示意：

![66867a2b3f9990d6f56db94e24b1f20e.png][]

那么，从List中删除元素之后，List中被删元素后面的所有元素下标都发生前移，但是 `for` 循环的指针 `i` 是始终往后累加的，再处理下一个的时候，就可能会有部分元素被漏掉没有处理。

比如下图的示意， `i=0` 时，判断A元素需要删除，则直接删除；再循环时 `i=1` ，此时因为list中元素位置前移，导致B元素变成了原来下标为0的位置，直接被漏掉了：

![d49c29e94c8e9480b9056a17f7ae938f.png][]

所以到这里呢，也就可以知道为啥上面的代码执行后会出现漏网之鱼啦~

![9a48e9cf37a3dd97709becf0ae1eb80f.gif][]

### 正确方式 ###

见识了上面2个坑操作之后，那正确妥当的操作方式应该是怎么样的呢？

#### 迭代器方式 ####

诶？没搞错吧？前面不是刚说过foreach方式也是使用的迭代器，但是其实是坑操作吗？这里怎么又说迭代器模式是正确方式呢？

虽然都是基于迭代器，但是使用逻辑是不一样的，看下代码：

public List<UserDetail> filterAllDevDeptUsers(List<UserDetail> allUsers) {
        Iterator<UserDetail> iterator = allUsers.iterator();
        while (iterator.hasNext()) {
            // 判断部门如果属于dev,则直接剔除
            if ("dev".equals(iterator.next().getDepartment())) {
                // 这是重点，此处操作的是Iterator，而不是list
                iterator.remove();
            }
        }
        // 返回剩余的用户数据
        return allUsers;
    }

执行结果：

{id=3, name='王五', department='product'}
    {id=4, name='铁柱', department='pm'}

这次竟然直接执行成功了，且结果也是正确的。为啥呢？

![d637c6006a05c6614018915ab6f82e7c.gif][]

在前面 `foreach` 方式的时候，我们提过之所以会报错的原因，是由于直接修改了原始 `list` 数据而没有同步让 `Iterator` 感知到，所以导致 `Iterator` 操作前校验失败抛异常了。而此处的写法中，直接调用迭代器中的 `remove()` 方法，此操作会在调用集合的 `remove()` ， `add()` 方法后，将 `expectedModCount` 重新赋值为 `modCount` ，所以在迭代器中增加、删除元素是可以正常运行的。，所以这样就不会出问题啦。

![7fd602398944c0911b4898166cc5e6f6.png][]

![a9f815e2fb87f1f69797939553e749d6.gif][]

#### Lumbda表达式 ####

言简意赅，直接上代码：

public List<UserDetail> filterAllDevDeptUsers(List<UserDetail> allUsers) {
        allUsers.removeIf(user -> "dev".equals(user.getDepartment()));
        return allUsers;
    }

![111dff349fe027f71c74303b948edc00.gif][]

#### Stream流操作 ####

作为JAVA8开始加入的Stream，使得这种场景实现起来更加的优雅与易懂：

public List<UserDetail> filterAllDevDeptUsers(List<UserDetail> allUsers) {
        return allUsers.stream()
                .filter(user -> !"dev".equals(user.getDepartment()))
                .collect(Collectors.toList());
    }

![a9f815e2fb87f1f69797939553e749d6.gif][]

#### 中间对象辅助方式 ####

既然前面说了不能直接循环的时候执行移除操作，那就先搞个list对象将需要移除的元素暂存起来，最后一起剔除就行啦 ~

嗯，虽然有点挫，但是不得不承认，实际情况中，很多人都在用这个方法：

public List<UserDetail> filterAllDevDeptUsers(List<UserDetail> allUsers) {
        List<UserDetail> needRemoveUsers = new ArrayList<>();
        for (UserDetail user : allUsers) {
            if ("dev".equals(user.getDepartment())) {
                needRemoveUsers.add(user);
            }
        }
        allUsers.removeAll(needRemoveUsers);
        return allUsers;
    }

或者：

public List<UserDetail> filterAllDevDeptUsers(List<UserDetail> allUsers) {
        List<UserDetail> resultUsers = new ArrayList<>();
        for (UserDetail user : allUsers) {
            if (!"dev".equals(user.getDepartment())) {
                resultUsers.add(user);
            }
        }
        return resultUsers;
    }
    
    ![](https://veezean-pics-1301558317.cos.ap-nanjing.myqcloud.com/pics/202207050811299.gif)

![fb9b35180d5194559d0640589c47489f.gif][]

### 回顾 ###

好啦，关于JAVA中循环场景中对列表操作的相关内容我们就聊这么多了~ 你有踩过上面的坑么？你还有什么更好的方式来实现吗？欢迎一起讨论交流~

![e1601155fbd3464b9f3de2c84279a105.jpeg][]

[f0fb8166e8f77ca4c3e77e3a2928c63d.gif]: https://img-blog.csdnimg.cn/img_convert/f0fb8166e8f77ca4c3e77e3a2928c63d.gif
[95888a47a76c98efbd44427c5d2d072c.gif]: https://img-blog.csdnimg.cn/img_convert/95888a47a76c98efbd44427c5d2d072c.gif
[fb9454b62a82433d0f6aba8b085b95f3.png]: https://img-blog.csdnimg.cn/img_convert/fb9454b62a82433d0f6aba8b085b95f3.png
[43aff1043126b3a3bc3a3a1e28c1b839.gif]: https://img-blog.csdnimg.cn/img_convert/43aff1043126b3a3bc3a3a1e28c1b839.gif
[af21ebc60fac18bd7a568e2d32ae7681.gif]: https://img-blog.csdnimg.cn/img_convert/af21ebc60fac18bd7a568e2d32ae7681.gif
[66867a2b3f9990d6f56db94e24b1f20e.png]: https://img-blog.csdnimg.cn/img_convert/66867a2b3f9990d6f56db94e24b1f20e.png
[d49c29e94c8e9480b9056a17f7ae938f.png]: https://img-blog.csdnimg.cn/img_convert/d49c29e94c8e9480b9056a17f7ae938f.png
[9a48e9cf37a3dd97709becf0ae1eb80f.gif]: https://img-blog.csdnimg.cn/img_convert/9a48e9cf37a3dd97709becf0ae1eb80f.gif
[d637c6006a05c6614018915ab6f82e7c.gif]: https://img-blog.csdnimg.cn/img_convert/d637c6006a05c6614018915ab6f82e7c.gif
[7fd602398944c0911b4898166cc5e6f6.png]: https://img-blog.csdnimg.cn/img_convert/7fd602398944c0911b4898166cc5e6f6.png
[a9f815e2fb87f1f69797939553e749d6.gif]: https://img-blog.csdnimg.cn/img_convert/a9f815e2fb87f1f69797939553e749d6.gif
[111dff349fe027f71c74303b948edc00.gif]: https://img-blog.csdnimg.cn/img_convert/111dff349fe027f71c74303b948edc00.gif
[fb9b35180d5194559d0640589c47489f.gif]: https://img-blog.csdnimg.cn/img_convert/fb9b35180d5194559d0640589c47489f.gif
[e1601155fbd3464b9f3de2c84279a105.jpeg]: https://img-blog.csdnimg.cn/e1601155fbd3464b9f3de2c84279a105.jpeg