在ArrayList.trimToSize（）中，如果实际上没有发生结构更改，为什么modCount会发生冲突

Question

例如：

public void trimToSize() {
    modCount++;
    if (size < elementData.length) {
        elementData = Arrays.copyOf(elementData, size);
    }
}

为什么在if里面没有modCount增量？

似乎modCount计算结构修改意图而不是有效的结构修改。

Answer 1

看看ArrayList的实现，我不明白为什么trimToSize()和ensureCapacity()都增加了modCount 。 即使存在elementData数组的实际重新分配，它们也不会更改列表的逻辑视图。

modCount用于确保列表中具有视图（迭代器，子列表）的对象可以检测基础列表上的修改（添加，删除，设置）。

在单线程环境中，通过调用ensureCapacity() ，什么情况实际上可能使列表上的迭代器无效？ 因为迭代器存储的是在调用trimToSize()或ensureCapacity() 不会改变的逻辑索引。

一个原因（我从我对源代码的理解中猜测） ensureCapacity()增加modCount是它被所有add()系列方法调用（在add()甚至还有一个注释不执行modCount++ 因为它完成了通过ensureCapacity() ）。

我可能错了 - 这两种方法有可能使迭代器无效 - 但如果不是这种情况，一些评论者提出的标记打算修改列表的原因并不成立：

trimToSize()调整内部数组的大小以删除未使用的插槽。 这些从未被迭代器或子列表使用，并且用户/调用者无意修改列表内容。 唯一的目的是节省一些记忆。
ensureCapacity()情况完全相同：不可能缩小列表。 如果用户调用此方法，则需要进行优化并在添加元素之前进行一些正确的调整。

作为最后的想法，我会更进一步：当调用这些方法中的任何一个时，用户不应该在迭代中期望一些ConcurrentMdificationException 。

Answer 2

根据http://docs.oracle.com/javase/6/docs/api/java/util/AbstractList.html#modCount和各种SO问题，modCount用于跟踪可能与迭代过程同时进行的修改。

如果我们假设一个方法会在modCount更改时抛出异常，这实际上意味着ArrayList会对意图作出反应，正如您所说，通知用户某些东西正在尝试更改它。