5

JAVA中简单的for循环竟有这么多坑,你踩过吗 - 架构悟道

 1 year ago
source link: https://www.cnblogs.com/softwarearch/p/16450200.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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

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

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

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

倘若不幸踩中:

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

202207050811299.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 弄啥嘞?咋抛异常了?

202206261511925.gif

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

原因分析:

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

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

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

202207051846860.png

202207050811299.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这种本应被剔除掉的数据呢?

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

202206261508327.gif

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

原因分析:

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

202207051904508.png

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

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

202207051907534.png

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

202207050811299.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'}

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

202206261513878.gif

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

202207051928343.png

202207050811299.gif

Lumbda表达式

言简意赅,直接上代码:


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


202207050811299.gif

Stream流操作

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


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

202207050811299.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)

202207050811299.gif

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

202207050811299.gif


我是悟道,聊技术、又不仅仅聊技术~

如果觉得有用,请点个关注,也可以关注下我的公众号【架构悟道】,获取更及时的更新。

期待与你一起探讨,一起成长为更好的自己。

gongzhonghao2.png

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK