调整并发哈希表大小

Question

Concurrent Hash Map 调整大小的内存惩罚是多少？具体而言，我需要了解以下内容：

Q1: 并发哈希映射的大小是否会增加一倍？我所读的资料表明调整大小是按照桶进行的，但并未指出桶数量的增加。

Q2: 如果并发哈希映射的大小增加了，节点如何移动到正确的桶中，因为哈希码现在可能不同。具体而言，元素是根据哈希码添加的，那么重新哈希后，节点是如何移动的？

- Desert Ice

---

这是两个问题合在一起，你可能想要分开提问。 - Duncan Jones

我猜你所说的"resize"是指增加映射内部哈希表中的桶数。至于你所说的"size"如何衡量（占用内存还是哈希桶的数量），我不太确定，但无论哪种方式，在"resize"过程中这些变化都没有被记录下来。如果这对你很重要，你应该能从源代码中确定这些变化。 - John Bollinger

元素重新哈希期间的详细处理方式也没有记录，但操作必须大致等同于从空映射开始并添加每个元素。在这样的重新哈希过程中，将会有一种额外的临时数据结构来保存对每个元素的引用。很可能这个数据结构就是原始哈希表。 - John Bollinger

Answer 1

1. 这是一个实现细节，有意不予记录。通过不记录它，JDK开发人员可以自由地进行性能改进和权衡，而不会破坏任何合同。您应该避免编写任何假设未记录行为的代码，例如集合将如何调整大小。如果您有兴趣阅读，当前实现在class's comments中有记录，但请注意，它们随时间可能会更改。

2. 同样，这也是一项实现细节，但您的声明“哈希码现在可能不同”是不正确的；文档已经记录了HashMap和ConcurrentHashMap在面对具有可变哈希码的键时表现不正确。因此，我们可以假定哈希码不会更改-只有存储对象的位置会更改。

   例如，假设我们的分桶算法只是hashcode％size - 如果一个bin有4个插槽，对象的哈希码为78，则会放置在bin 2中（78％4 = 2）。如果bin调整大小为8个插槽，则对象将移动到bin 6中（78％8 = 6）。 JDK类使用更优雅的分桶算法，但概念相同。

- dimo414