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

问题描述

ArrayList 和 HashMap 都有构造函数来设置初始容量，但 ArrayList 提供了 ensureCapacity（），以确保如果预计要插入一定数量的元素，内部数组已经增加。在某些情况下，也可能发生 HashMap 。那么为什么 HashMap 没有一个确保容量的方法可以保证桶已经准备好？

解决方案<简单的回答是，它不是非常有用。

结构像 ArrayList 和 HashMap 有一个 capacity 的概念，它是用户不能直接看到的一些内部数组的长度。容量不同于 size ，它是逻辑上包含在结构中的元素或条目的数量。

容量一词是这实际上并不恰当，因为它实际上并不代表对用户来说很重要的任何限制。这是一个实现细节。随着元素或条目的添加，内部数组将自动且透明地调整大小。没有更改容量的语义。您无法判断对 ensureCapacity（）的调用是否实际改变了容量，并且如果确实改变了容量，则列表或地图仍等于它等于之前。

在API中拥有容量概念的原因是在用户知道很多元素正在运行的情况下提高性能被添加。这有助于避免在用户知道要添加大量元素的情况下重复调整大小的开销。最常见的情况是在施工时，最有可能知道要添加多少元素。

请注意，批量添加方法（ addAll 或 putAll ）将查看即将添加的内容的大小，并执行任何必要的调整大小如果你有一个你想要的现有列表，你可以调用 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屋！