为什么 hashmap 没有像 ArrayList 那样的 ensureCapacity() 方法? [英] Why does hashmap does not have ensureCapacity() method like ArrayList?

查看:22
本文介绍了为什么 hashmap 没有像 ArrayList 那样的 ensureCapacity() 方法?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

ArrayListHashMap 都具有设置初始容量的构造函数,但 ArrayList 提供了 ensureCapacity() 以确保如果预期插入大量元素,则内部数组已经增加.在某些情况下,HashMap 也会发生同样的情况.那么为什么 HashMap 没有一个确保存储桶准备就绪的容量方法?

解决方案

简而言之,它不是很有用.

ArrayListHashMap这样的结构有一个容量的概念,它是一些内部数组的长度,它不是直接可见的用户.容量不同于大小,后者是逻辑上包含在结构中的元素或条目的数量.

容量"这个词确实用词不当,因为它实际上并不代表对用户很重要的任何限制.这是一个实现细节.随着元素或条目的添加,内部数组将自动且透明地调整大小.改变容量没有语义.你无法判断对 ensureCapacity() 的调用是否真的改变了容量,如果它确实改变了容量,列表或地图仍然等于它之前等于的任何东西.>

在 API 中完全包含容量概念的原因是在用户知道将添加大量元素的情况下提高性能.这有助于避免重复调整大小的开销,以防用户知道将添加大量元素.最常见的情况是在构建时,您很可能会知道要添加多少元素.

请注意,批量添加方法(addAllputAll)将查看将要添加的内容的大小,并对目标进行任何必要的调整大小一次.

如果您有一个要向其中添加大量元素的现有列表,则可以调用 Arraylist.ensureCapacity();您很清楚将要添加多少个;您必须一次添加一个,而不是批量添加;并且您的应用程序对性能非常敏感,您必须避免多次调整大小.这似乎很少见.

可以想象一个 API HashMap.ensureCapacity().如有必要,它会调整内部表的大小,然后将所有元素重新散列到该表的桶中.如果将来添加了大量条目,这将有助于避免重复调整大小/重新哈希.这在语义上是合理的做法,但真正有用的情况似乎很少.

最重要的是,可以添加 HashMap.ensureCapacity(),但它的用途很少,因此从来没有优先考虑添加它.

ArrayList and HashMap both have constructors to set initial capacity yet ArrayList provides ensureCapacity() to ensure that internal array is already increased if some good amount of elements are expected to be inserted. Same can happen with a HashMap too in some situation. Then why does HashMap not have an ensure capacity method that will already keep the buckets ready?

解决方案

The short answer is, it's not very useful.

Structures like ArrayList and HashMap have a concept of capacity, which is the length of some internal array that isn't directly visible to users. The capacity is distinct from the size, which is the number of elements or entries logically contained in the structure.

The word "capacity" is really a misnomer, as it doesn't actually represent any limit that's significant to users. It's an implementation detail. As elements or entries are added, internal arrays will be resized automatically and transparently. There are no semantics to changing the capacity. You can't tell whether a call to ensureCapacity() has actually changed the capacity, and if it did change the capacity, the list or map is still equal to anything it was equal to before.

The reason for having the notion of capacity at all in the API is to improve performance in the cases where the user knows that a lot of elements are going to be added. This helps avoid the overhead of repeated resizing, in cases where the user knows that a lot of elements are going to be added. The most common case for this is at construction time, where it's most likely that you'll know how many elements you're going to add.

Note that the batch addition methods (addAll or putAll) will look at the size of what's about to be added, and do any necessary resizing of the destination once.

You'd call Arraylist.ensureCapacity() if you have an existing list that you want to add lot of elements to; you have a good idea of how many are going to be added; you have to add them one at a time, instead of in a batch; and your application is so performance-sensitive that you have to avoid multiple resizing. This seems pretty rare.

One could imagine an API HashMap.ensureCapacity(). If necessary, it would resize the internal table, and then rehash all the elements into the buckets of this table. This would help avoid repeated resizes/rehashes if a lot of entries were added in the future. This is a semantically a reasonable thing to do, but the number of cases where it's really useful seems quite small.

The bottom line is that HashMap.ensureCapacity() could be added, but there's little enough use for it that it's never been a priority to add it.

这篇关于为什么 hashmap 没有像 ArrayList 那样的 ensureCapacity() 方法?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆