java内存开销_java – 缩小集合的内存开销

你是对的,大多数集合都有一个自动扩展的内部容量,而且永远不会缩小. ArrayList是个例外,它有方法ensureCapacity()和trimToSize(),让应用程序可以显式管理列表的内部容量.在实践中,我认为这些方法很少使用.

增长但不自动收缩的政策是基于对集合使用模型的一些假设:

>应用程序通常不知道要存储多少元素,因此集合将在添加元素时自动扩展;

>一旦收集完全填充,元素的数量通常将保持在该数字附近,既不增长也不显着缩小;

>与元素本身的大小相比,集合的每元素开销通常很小.

对于符合这些假设的应用程序,该策略似乎运行得相当好.例如,假设您将一百万个键值对插入HashMap.默认加载因子为0.75,因此内部表大小为133万.表格大小向上舍入到下一个2的幂,即2 ^ 21(2,097,152).从某种意义上说,地图的内部表中有大约一百万个“额外”的插槽.由于每个插槽通常是一个4字节的对象引用,这是4MB的浪费空间!

但请注意,您使用此地图存储了一百万个键值对.假设每个键和值是50个字节(这似乎是一个非常小的对象).这是100MB来存储数据.相比之下,4MB的额外地图开销并不是什么大不了的事.

但是假设你已经存储了一百万个映射,并且你想要遍历所有映射并删除除了一百个感兴趣的映射之外的所有映射.现在你要存储10KB的数据,但是你的地图的2 ^ 21个元素的表占用了8MB的空间.那是很多浪费.

但似乎从地图中执行999,900次删除也是不太可能的事情.如果要保留100个映射,可能需要创建一个新映射,只插入要保留的100个映射,然后丢弃原始映射.这样可以消除空间浪费,也可能会快得多.鉴于此,在实践中缺乏收集的自动收缩政策通常不是问题.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值