java - 在ArrayList.trimToSize()中，如果实际上没有发生结构更改，为什么modCount会被颠簸

例如:

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

为什么if中的modCount不增加？

好像modCount计算的是结构修改的意图，而不是有效的结构修改。

最佳答案

查看ArrayList的实现，我看不到trimToSize()和ensureCapacity()为什么都增加modCount。即使实际重新分配了elementData数组，它们也不会更改列表的逻辑视图。
modCount用于确保在列表上具有视图(迭代器，子列表)的对象可以检测对基础列表的修改(添加，删除，设置)。

在单线程环境中，哪种情况实际上可以通过调用ensureCapacity()使列表中的迭代器无效？由于迭代器存储的逻辑索引在调用trimToSize()或ensureCapacity()时不变。
ensureCapacity()增加modCount的一个原因(我认为是对源代码的理解)是所有add()族方法都调用了它(在add() 中甚至没有注释，不要对做modCount++ ，因为由ensureCapacity()完成)。

我可能是错的-并且这两种方法都有可能使迭代器无效-但是，如果不是这种情况，某些评论者提出的标记要修改列表的意图的理由不成立:

trimToSize()调整内部数组的大小以删除未使用的插槽。迭代器或子列表永远不会使用这些内容，并且用户/调用者无意修改列表内容。唯一的目的是节省一些内存。

ensureCapacity()的情况完全相同:不可能缩小列表。如果用户调用此方法，则该方法用于优化并在添加元素之前进行一些适当的调整大小。

最终的想法是，我走得更远:调用这些方法中的任何一个时，用户都不应在迭代中期望一些ConcurrentMdificationException。