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

    Java Collection类的某些详细实现因为底层数据存储基于数组,随着元素数量的添加,调整大小的代价非常大。随着Collection元素增长到某个上限,调整其大小可能出现性能问题。

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

    当调整数组大小仍有一个问题。新拷贝的数组引用元素可能被JVM分配的位置可能与Collection类中的其它字段引用不在同一块内存存储,这可能导致CPU快速缓存未命中(一般而言,对象与其字段须要同一时候訪问,将对象与其字段放在尽可能相邻位置的内存位置将添加CPU内存命中率),訪问字段的时间将会加长(尽管非常快)。


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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值