Java:无法更改迭代器列表
我有一个 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果基础列表发生更改,则在此之前获取的迭代器将抛出 ConcurrentModificationException。因此不要将迭代器存储在实例字段中。
If the underlying list changes, the iterator that was obtained before that throws
ConcurrentModificationException
. So don't store iterators in instance fields.我们可以肯定地说,
ConcurrentModificationException
意味着底层可迭代对象在调用获取迭代器之后的某个时刻已被修改。这并不总是意味着多线程中的并发;通过迭代列表并在循环期间删除元素,可以轻松触发此异常。因此,如果没有其他线程可能修改它,那么我们可以说当前线程在某个时刻修改了迭代器的底层数据结构。
这里没有足够的代码可以确定,但是您存储迭代器的做法有点可疑。您什么时候将(内部)迭代器添加到 mPoints 中?如果它们引用的集合在创建迭代器后随时发生变化,则在调用时将抛出此异常。因此,一旦您将迭代器添加到 mPoints 集合中,迭代器的数据结构就会被有效地锁定以进行更改,但这在代码中根本不会很清楚。
所以我怀疑这是你问题的根本原因。除非它是非常短期的(并且通常在单个词法范围内,例如单个方法调用),否则存储迭代器可能不是一个好主意,因为您所看到的原因。最好存储对底层集合本身的引用,然后在上面的代码块中创建迭代器,如下所示:
然后,确切的解决方案又取决于方法的总体架构。要记住的主要事情是不要长期存储迭代器,因为几乎不可能使这项工作可靠。即使它现在确实有效,它也会在代码的不同部分之间创建一种无形的依赖关系,而这种依赖关系几乎总是会被实现本应是微不足道的更改的人所打破。
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 themPoints
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:
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.