为什么一个循环会抛出 ConcurrentModificationException，而另一个循环则不会？

发布于 2024-08-24 17:56:01 字数 382 浏览 12 评论 0原文

我在编写旅行推销员程序时遇到了这个问题。对于内部循环，我尝试了一个

for(Point x:ArrayList<Point>) {
// modify the iterator
}

，但是当向该列表添加另一个点时，导致抛出 ConcurrentMominationException 。

但是，当我将循环更改为

for(int x=0; x<ArrayList<Point>.size(); x++) {
// modify the array
}

循环时，循环运行良好，没有引发异常。

两者都是 for 循环，那么为什么一个会抛出异常而另一个不会呢？

原文

I've run into this while writing a Traveling Salesman program. For an inner loop, I tried a

for(Point x:ArrayList<Point>) {
// modify the iterator
}

but when adding another point to that list resulted in a ConcurrentModicationException being thrown.

However, when I changed the loop to

for(int x=0; x<ArrayList<Point>.size(); x++) {
// modify the array
}

the loop ran fine without throwing an exception.

Both a for loops, so why does one throw an exception while the other does not?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

沙与沫 2024-08-31 17:56:01

正如其他人所解释的，迭代器检测对底层集合的修改，这是一件好事，因为它可能会导致意外的行为。

想象一下这个修改集合的无迭代器代码：

for (int x = 0; list.size(); x++)
{
  obj = list.get(x);
  if (obj.isExpired())
  {
    list.remove(obj);
    // Oops! list.get(x) now points to some other object so if I 
    // increase x again before checking that object I will have 
    // skipped one item in the list
  }
}

As others explained, the iterator detects modifications to the underlying collection, and that is a good thing since it is likely to cause unexpected behaviour.

Imagine this iterator-free code which modifies the collection:

for (int x = 0; list.size(); x++)
{
  obj = list.get(x);
  if (obj.isExpired())
  {
    list.remove(obj);
    // Oops! list.get(x) now points to some other object so if I 
    // increase x again before checking that object I will have 
    // skipped one item in the list
  }
}

回复收藏 0 原文