Java for-each 删除元素实测删倒数第二个不抛异常因为 hasNext 判的是 !16:37控制台第一行出来3 个元素删第一个抛了ConcurrentModificationException。这题我压根没打算跑。for 循环里删元素会抛异常Java 的常识。第二行就不对了。16:38 第二行3 个元素删第二个没抛。结果[a, c]。我盯着这行看了半天。同一个写法同样是在循环里删位置挪了一下异常没了有点邪门。16:38 一口气跑五种位置5 个元素从第一个删到第五个。每轮重新建一个 list记三件事抛没抛、循环体实际进了几次、删完剩几个。位置 | 原始size | 实际访问了几个 | 删后size | 结果 0 | 5 | 1 | 4 | 抛 1 | 5 | 2 | 4 | 抛 2 | 5 | 3 | 4 | 抛 3 | 5 | 4 | 4 | 没抛剩 [a, b, c, e] 4 | 5 | 5 | 4 | 抛CME 是 ConcurrentModificationException控制台打出来一长串表格里我简写了。第四行是重点。位置 3倒数第二个元素。删掉它一次异常都没抛循环体只进了 4 次。5 个元素末尾那个e从头到尾没被看过。这段代码既没报错也没干完活。16:39 去翻 hasNextJDK 8 的ArrayList内部类Itr第 853 行publicbooleanhasNext(){returncursor!size;}判的是!不是。平时看着差不多在这里差得远。cursor是下一个要返回的下标。走完位置 3cursor 已经是 4。删掉一个元素size 从 5 变成 4。hasNext一比4 ! 4false循环结束。它不觉得自己漏了一个它觉得正好走完。那怎么别的位置就抛删完 size 也变小可 cursor 落在 size 里面hasNext还返回 true进next()。next()第一行是checkForComodification()拿modCount和expectedModCount比你删元素的时候 modCount 加过 1两边不相等抛。删的位置越靠后越容易撞上那个“正好相等”。16:40 换成手写下标一样漏增强 for 有这毛病那手写下标呢。ListStringlnewArrayList(Arrays.asList(a,b,b,c));for(inti0;il.size();i){if(l.get(i).equals(b))l.remove(i);}跑出来[a, b, c]。两个 b只删掉一个剩下那个还在循环已经走过去了。删完元素往前挪i 还往前走一格正好跳过下一个。补一句i--才对得上跑出来[a, c]。这毛病跟写法没关系是“边遍历边改长度”这件事本身有坑。增强 for 把它变成抛异常或者静默结束手写下标是安安静静漏掉连个响都没有。顺手又试了删两个相邻的 b还是那个异常list 剩下[a, b, c]。删第一个的时候异常还没触发第二个才炸。这种一半成功一半失败的状态最难恢复。麻烦的不是抛异常抛异常其实是好事。日志一眼能看见测试一跑就红。麻烦的是不抛的那种。它跑完了结果少了元素界面上看不出来接口也不报错。你只能在业务对不上数的时候回头看还未必想到是循环里删的。这种代码还有个特点换一份数据就变脸。今天删的元素正好排在倒数第二安安静静跑完。明天数据多一条少一条位置变了开始抛异常。同一段代码昨天没事今天有事谁都说不清。它也不只出现在清理任务里。批量改状态、批量删缓存、批量下线账号只要是在 for 里按条件删都有这个位置问题。JDK 为什么不把hasNext里的!改成顺手把这个坑填了。改也白改位置 3 那种会从静默结束变成抛异常位置 0 照样抛。集合在遍历期间不许改这条规矩从第一天就定死了换个符号兜不住。线上再看到这个异常我先翻堆栈第一行。要是ArrayList$Itr.next直接去搜当前类的增强 for十有八九里头藏着remove。改法就两种第一种用IteratorIteratorStringitlist.iterator();while(it.hasNext()){Stringsit.next();if(b.equals(s)||d.equals(s)){it.remove();}}跑出来[a, c, e]。Iterator.remove()里干了两件事删完之后把 cursor 退回去一格再把expectedModCount重新对上modCount。所以它删一个跳一格不重不漏。第二种JDK 8 之后直接removeIflist.removeIf(x-b.equals(x)||d.equals(x));跑出来也是[a, c, e]。三行变一行还不用自己管迭代器。这两个我都在同一台机器上跑过JDK 1.8.0_211输出一样。收工前搜索框里敲for (再用眼睛过一遍循环体带remove(、add(、clear(的都算可疑。这种写法在老项目里不难找一个业务类翻两页就能撞见。add也一样会抛只是数据少的时候循环提前结束看不出来。现在看到for (X x : list)里面带remove的代码我基本不看它能不能跑通直接改。它能跑通可能只是数据刚好排成了那个样子。从 16:37 开始到 16:41 收工四分钟。四分钟能查清的东西线上可能要查四天。
Java for-each 删除元素实测删倒数第二个不抛异常因为 hasNext 判的是 !16:37控制台第一行出来3 个元素删第一个抛了ConcurrentModificationException。这题我压根没打算跑。for 循环里删元素会抛异常Java 的常识。第二行就不对了。16:38 第二行3 个元素删第二个没抛。结果[a, c]。我盯着这行看了半天。同一个写法同样是在循环里删位置挪了一下异常没了有点邪门。16:38 一口气跑五种位置5 个元素从第一个删到第五个。每轮重新建一个 list记三件事抛没抛、循环体实际进了几次、删完剩几个。位置 | 原始size | 实际访问了几个 | 删后size | 结果 0 | 5 | 1 | 4 | 抛 1 | 5 | 2 | 4 | 抛 2 | 5 | 3 | 4 | 抛 3 | 5 | 4 | 4 | 没抛剩 [a, b, c, e] 4 | 5 | 5 | 4 | 抛CME 是 ConcurrentModificationException控制台打出来一长串表格里我简写了。第四行是重点。位置 3倒数第二个元素。删掉它一次异常都没抛循环体只进了 4 次。5 个元素末尾那个e从头到尾没被看过。这段代码既没报错也没干完活。16:39 去翻 hasNextJDK 8 的ArrayList内部类Itr第 853 行publicbooleanhasNext(){returncursor!size;}判的是!不是。平时看着差不多在这里差得远。cursor是下一个要返回的下标。走完位置 3cursor 已经是 4。删掉一个元素size 从 5 变成 4。hasNext一比4 ! 4false循环结束。它不觉得自己漏了一个它觉得正好走完。那怎么别的位置就抛删完 size 也变小可 cursor 落在 size 里面hasNext还返回 true进next()。next()第一行是checkForComodification()拿modCount和expectedModCount比你删元素的时候 modCount 加过 1两边不相等抛。删的位置越靠后越容易撞上那个“正好相等”。16:40 换成手写下标一样漏增强 for 有这毛病那手写下标呢。ListStringlnewArrayList(Arrays.asList(a,b,b,c));for(inti0;il.size();i){if(l.get(i).equals(b))l.remove(i);}跑出来[a, b, c]。两个 b只删掉一个剩下那个还在循环已经走过去了。删完元素往前挪i 还往前走一格正好跳过下一个。补一句i--才对得上跑出来[a, c]。这毛病跟写法没关系是“边遍历边改长度”这件事本身有坑。增强 for 把它变成抛异常或者静默结束手写下标是安安静静漏掉连个响都没有。顺手又试了删两个相邻的 b还是那个异常list 剩下[a, b, c]。删第一个的时候异常还没触发第二个才炸。这种一半成功一半失败的状态最难恢复。麻烦的不是抛异常抛异常其实是好事。日志一眼能看见测试一跑就红。麻烦的是不抛的那种。它跑完了结果少了元素界面上看不出来接口也不报错。你只能在业务对不上数的时候回头看还未必想到是循环里删的。这种代码还有个特点换一份数据就变脸。今天删的元素正好排在倒数第二安安静静跑完。明天数据多一条少一条位置变了开始抛异常。同一段代码昨天没事今天有事谁都说不清。它也不只出现在清理任务里。批量改状态、批量删缓存、批量下线账号只要是在 for 里按条件删都有这个位置问题。JDK 为什么不把hasNext里的!改成顺手把这个坑填了。改也白改位置 3 那种会从静默结束变成抛异常位置 0 照样抛。集合在遍历期间不许改这条规矩从第一天就定死了换个符号兜不住。线上再看到这个异常我先翻堆栈第一行。要是ArrayList$Itr.next直接去搜当前类的增强 for十有八九里头藏着remove。改法就两种第一种用IteratorIteratorStringitlist.iterator();while(it.hasNext()){Stringsit.next();if(b.equals(s)||d.equals(s)){it.remove();}}跑出来[a, c, e]。Iterator.remove()里干了两件事删完之后把 cursor 退回去一格再把expectedModCount重新对上modCount。所以它删一个跳一格不重不漏。第二种JDK 8 之后直接removeIflist.removeIf(x-b.equals(x)||d.equals(x));跑出来也是[a, c, e]。三行变一行还不用自己管迭代器。这两个我都在同一台机器上跑过JDK 1.8.0_211输出一样。收工前搜索框里敲for (再用眼睛过一遍循环体带remove(、add(、clear(的都算可疑。这种写法在老项目里不难找一个业务类翻两页就能撞见。add也一样会抛只是数据少的时候循环提前结束看不出来。现在看到for (X x : list)里面带remove的代码我基本不看它能不能跑通直接改。它能跑通可能只是数据刚好排成了那个样子。从 16:37 开始到 16:41 收工四分钟。四分钟能查清的东西线上可能要查四天。
