Java:无法更改迭代器列表

发布于 2024-10-02 01:22:34 字数 457 浏览 3 评论 0原文

我有一个 ListIterator 列表作为类字段。我将其填充到方法 grow() 中。当我尝试使用此列表中的迭代器时,我收到 ConcurrentModificationException。

ListIterator<ListIterator<PointF>> i = mPoints.listIterator();
while (i.hasNext()) {
    ListIterator<PointF> j = i.next();
    if (j.hasNext())
        PointF tmp = j.next(); // Exception here
}

我不知道为什么这段代码会在任何方法中导致异常 除了 grow()

I have a list of ListIterator<PointF> as a class field. I fill it in method grow(). When i try to use iterators from this list i get ConcurrentModificationException.

ListIterator<ListIterator<PointF>> i = mPoints.listIterator();
while (i.hasNext()) {
    ListIterator<PointF> j = i.next();
    if (j.hasNext())
        PointF tmp = j.next(); // Exception here
}

I have no idea why does this code causes exeption in any method besides grow()

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

雨巷深深 2024-10-09 01:22:34

如果基础列表发生更改,则在此之前获取的迭代器将抛出 ConcurrentModificationException。因此不要将迭代器存储在实例字段中。

If the underlying list changes, the iterator that was obtained before that throws ConcurrentModificationException. So don't store iterators in instance fields.

南城追梦 2024-10-09 01:22:34

我们可以肯定地说,ConcurrentModificationException 意味着底层可迭代对象在调用获取迭代器之后的某个时刻已被修改。

这并不总是意味着多线程中的并发;通过迭代列表并在循环期间删除元素,可以轻松触发此异常。因此,如果没有其他线程可能修改它,那么我们可以说当前线程在某个时刻修改了迭代器的底层数据结构。

这里没有足够的代码可以确定,但是您存储迭代器的做法有点可疑。您什么时候将(内部)迭代器添加到 mPoints 中?如果它们引用的集合在创建迭代器后随时发生变化,则在调用时将抛出此异常。因此,一旦您将迭代器添加到 mPoints 集合中,迭代器的数据结构就会被有效地锁定以进行更改,但这在代码中根本不会很清楚。

所以我怀疑这是你问题的根本原因。除非它是非常短期的(并且通常在单个词法范围内,例如单个方法调用),否则存储迭代器可能不是一个好主意,因为您所看到的原因。最好存储对底层集合本身的引用,然后在上面的代码块中创建迭代器,如下所示:

ListIterator<Iterable<PointF>> i = mPoints.listIterator();
while (i.hasNext()) {
    Iterator<PointF> j = i.next().iterator();
    if (j.hasNext())
        PointF tmp = j.next();
}

然后,确切的解决方案又取决于方法的总体架构。要记住的主要事情是不要长期存储迭代器,因为几乎不可能使这项工作可靠。即使它现在确实有效,它也会在代码的不同部分之间创建一种无形的依赖关系,而这种依赖关系几乎总是会被实现本应是微不足道的更改的人所打破。

What we can say for sure is that a ConcurrentModificationException means that the underlying iterable has been modified at some point after your call to get the iterator.

This does not always mean concurrent as in multi-threaded; one can easily trigger this exception by iterating through a list and deleting elements during the loop. So, if there are no other threads potentially modifying this, then we can say that the current thread has modified an iterator's underlying data structure at some point.

There's not enough code here to be sure, but your practice of storing iterators is a little suspicious. When did you add the (inner) iterators to mPoints? If the collection they refer to changes at any time after the iterator was created, it will throw this exception when invoked. Hence as soon as you add an iterator to the mPoints collection, the iterator's data structure is effectively locked for changes, and yet this won't be very clear in the code at all.

So I suspect this is the root cause of your problem. Unless it's for a very short term (and usually within a single lexical scope, e.g. a single method invocation) it's probably a bad idea to store iterators for the reason you're seeing. It might be better to store a reference to the underlying collections themselves, and then create the iterators during the code block above, something like:

ListIterator<Iterable<PointF>> i = mPoints.listIterator();
while (i.hasNext()) {
    Iterator<PointF> j = i.next().iterator();
    if (j.hasNext())
        PointF tmp = j.next();
}

Then again the exact solution depends on the general architecture of your method. The main thing to bear in mind is don't store iterators long-term, because it's almost impossible to make this work reliably. Even if it does work right now, it creates a kind of invisible dependency between different parts of your code that will almost invariably be broken by someone implementing what should be a trivial change.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文