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

大家好，又见面啦~,实际的业务项目开发中，大家应该对从给定的list中剔除不满足条件的元素这个操作不陌生吧？,很多同学可以立刻想出很多种实现的方式，但你想到的这些实现方式都是人畜无害的吗？很多看似正常的操作其实背后是个陷阱，很多新手可能稍不留神就会掉入其中。,倘若不幸踩中：,那么，到底有哪些实现方式呢？哪些实现方式可能会存在问题呢？这里我们一起探讨下。注意哦，这里讨论的可不是茴香豆的“茴”字有有种写法的问题，而是很严肃很现实也很容易被忽略的技术问题。,假设需求场景：,给定一个用户列表allUsers，需要从该列表中剔除隶属部门为dev的人员，将剩余的人员信息返回。,很多新手的第一想法就是for循环逐个判断校验下然后符合条件的剔除掉就行了嘛~ so easy…,1分钟就把代码写完了：,然后信心满满的点击了执行按钮：,诶？what are you 弄啥嘞？咋抛异常了？,一不留神就踩坑里了，下面就一起分析下为啥会抛异常。,原因分析：,JAVA的foreach语法实际处理是基于迭代器Iterator进行实现的。,在循环开始时，会首先创建一个迭代实例，这个迭代实例的expectedModCount​ 赋值为集合的modCount​。而每当迭代器使⽤ hashNext()​ / next()​ 遍历下⼀个元素之前，都会检测 modCount​ 变量与expectedModCount​ 值是否相等，相等的话就返回遍历；否则就抛出异常ConcurrentModificationException，终⽌遍历。,如果在循环中添加或删除元素，是直接调用集合的add()，remove()​方法，导致了modCount​增加或减少，但这些方法不会修改迭代实例中的expectedModCount​，导致在迭代实例中expectedModCount​与 modCount的值不相等，抛出ConcurrentModificationException异常。,,嗯哼？既然foreach方式不行，那就用原始的下标循环的方式来搞，总不会报错了吧？依旧很easy …,代码一气呵成，执行一下，看下处理后的输出：,果然，不报错了，结果也输出了，完美~,等等？这样真的OK了吗？,我们的代码逻辑里面是判断如果"dev".equals(department)​，但是输出结果里面，为啥还是有department=dev这种本应被剔除掉的数据呢？,这里如果是在真实业务项目中，开发阶段不报错，又没有仔细去验证结果的情况下，流到生产线上，就可能造成业务逻辑的异常。,接下来看下出现这个现象的具体原因。,原因分析：,我们知道，list中的元素与下标之间，其实并没有强绑定关系，仅仅只是一个位置顺序的对应关系，list中元素变更之后，其每个元素对应的下标都可能会变更，如下示意：,,那么，从List中删除元素之后，List中被删元素后面的所有元素下标都发生前移，但是for​循环的指针i是始终往后累加的，再处理下一个的时候，就可能会有部分元素被漏掉没有处理。,比如下图的示意，i=0​时，判断A元素需要删除，则直接删除；再循环时i=1，此时因为list中元素位置前移，导致B元素变成了原来下标为0的位置，直接被漏掉了：,,所以到这里呢，也就可以知道为啥上面的代码执行后会出现漏网之鱼啦~​,见识了上面2个坑操作之后，那正确妥当的操作方式应该是怎么样的呢？,诶？没搞错吧？前面不是刚说过foreach方式也是使用的迭代器，但是其实是坑操作吗？这里怎么又说迭代器模式是正确方式呢？,虽然都是基于迭代器，但是使用逻辑是不一样的，看下代码：,执行结果：,这次竟然直接执行成功了，且结果也是正确的。为啥呢？,在前面foreach​方式的时候，我们提过之所以会报错的原因，是由于直接修改了原始list​数据而没有同步让Iterator​感知到，所以导致Iterator​操作前校验失败抛异常了。而此处的写法中，直接调用迭代器中的remove()​方法，此操作会在调用集合的remove()，add()​方法后，将expectedModCount​重新赋值为modCount，所以在迭代器中增加、删除元素是可以正常运行的。，所以这样就不会出问题啦。,,言简意赅，直接上代码：,作为JAVA8开始加入的Stream，使得这种场景实现起来更加的优雅与易懂：,既然前面说了不能直接循环的时候执行移除操作，那就先搞个list对象将需要移除的元素暂存起来，最后一起剔除就行啦 ~,嗯，虽然有点挫，但是不得不承认，实际情况中，很多人都在用这个方法：,或者：,好啦，关于JAVA中循环场景中对列表操作的相关内容我们就聊这么多了~ 你有踩过上面的坑么？你还有什么更好的方式来实现吗？