Java Collection类的某些具体实现由于底层数据存储基于数组，随着元素数量的增加，调整大小的代价很大。随着Collection元素增长到某个上限，调整其大小可能出现性能问题。

    当Collection元素达到内部数组达到最大值后，需要创建新数组，并且将旧数组元素通过Arrays.copyOf方法拷贝到新数组，这就消耗了CPU时间片，并且还需要进行垃圾回收，特别是当Collection对象生命周期较长，已经处于老年代，需要经历一次Full GC才能释放内存。新数组的内存会在年轻代的Eden区分配内存（当对象特别大时，可能不会分配在Eden区），并且需要两次进入Survivor区才能进入老年代，垃圾回收时的标记、清除等操作消耗的性能完全可以在初始化Collection时给定合理大小避免。

    当调整数组大小仍有一个问题。新拷贝的数组引用元素可能被JVM分配的位置可能与Collection类中的其他字段引用不在同一块内存存储，这可能导致CPU高速缓存未命中（一般而言，对象与其字段需要同时访问，将对象与其字段放在尽可能相邻位置的内存位置将增加CPU内存命中率），访问字段的时间将会加长（虽然很快）。

    注：本文考虑基于数组实现的Collection类，对于以链表如LinkedList、TreeMap等，不做探讨。

Java Collection 集合类大小调整带来的性能消耗