Hashmap loadfactor - 基于占用的桶数或所有桶中的条目数？答案

【问题标题】：Hashmap loadfactor - based on number of buckets occupied or number of entries in all buckets?Hashmap loadfactor - 基于占用的桶数或所有桶中的条目数？
【发布时间】：2018-06-10 10:58:01
【问题描述】：

我试图了解在超过占用的存储桶数或所有存储桶中的条目总数时会发生哈希映射的重新散列。意思是，我们知道如果 16 个桶中的 12 个（每个桶中有一个条目）已满（考虑默认负载因子和初始容量），那么我们知道在下一个条目上哈希图将被重新散列。但是如果假设只有 3 个存储桶被每个 4 个条目占用（总共 12 个条目，但 16 个存储桶中只有 3 个在使用中），那该怎么办？

所以我尝试通过制作最差的哈希函数来复制这一点，它将所有条目放在一个桶中。

这是我的代码。

class X {

    public Integer value;

    public X(Integer value) {
        super();
        this.value = value;
    }

    @Override
    public int hashCode() {
        return 1;
    }

    @Override
    public boolean equals(Object obj) {
        X a = (X) obj;
        if(this.value.equals(a.value)) {
            return true;
        }
        return false;
    }

}

现在我开始将值放入 hashmap 中。

HashMap<X, Integer> map = new HashMap<>();
    map.put(new X(1), 1);
    map.put(new X(2), 2);
    map.put(new X(3), 3);
    map.put(new X(4), 4);
    map.put(new X(5), 5);
    map.put(new X(6), 6);
    map.put(new X(7), 7);
    map.put(new X(8), 8);
    map.put(new X(9), 9);
    map.put(new X(10), 10);
    map.put(new X(11), 11);
    map.put(new X(12), 12);
    map.put(new X(13), 13);
    System.out.println(map.size());

所有节点都按预期进入了单个存储桶，但我注意到在第 9 个条目时，哈希图重新散列并使其容量增加了一倍。现在在第 10 次入境时，它的容量再次翻了一番。

谁能解释这是怎么回事？

提前致谢。

【问题讨论】：

javadoc 说：当哈希表中的条目数超过负载因子和当前容量的乘积时，哈希表被重新哈希。因此，占用的桶数无关紧要。重要的是条目的数量。
好的，谢谢你清除它，但考虑到上面的 hashmap 应该在第 13 个条目调整大小，但它在第 9 和第 10 又做了一次。为什么这样做？
您能阅读地图实现的源代码吗？
这是一个重现您的实验的类，首先使用 Integers 作为键（行为如文档所示），然后使用 X 作为键（行为“奇怪”）：gist.github.com/jnizet/34ca08ba0314c8e857ea9a161c175f13。如果桶太拥挤，HashMap 会变成树，代码说：“最小的表容量，bin 可以被树化。（否则，如果 bin 中有太多节点，表会调整大小。）”。因此，除了记录的内容外，该表还会在存储桶拥挤时自行调整大小，当容量变为 64 时，它会更改为树节点。
@JBNizet - 是的，该示例更好地复制了我的案例。是的，似乎一个拥挤的桶正在触发哈希图的双倍容量。您是否有一些来源或参考资料可以进一步解释这种对桶大小的重新散列？

标签： java hashmap load-factor

【解决方案1】：

在 HashMap 中，如果条目的哈希码相同，则条目将存在于同一个桶中。如果将唯一的 Integer 对象放在 hashMap 中，它们的 hashcode 肯定会改变，因为它们是不同的对象。

但在您的情况下，所有对象都具有相同的哈希码。这意味着您指定的所有条目都将位于一个存储桶中。这些桶中的每一个都遵循特定的数据结构（linkedList/tree）。这里的容量根据特定的数据结构和哈希图而变化。

我已经运行了评论中提到的 JB Nizet 的代码 (https://gist.github.com/jnizet/34ca08ba0314c8e857ea9a161c175f13/revisions)，循环限制为 64 和 128（添加 64 和 128 个元素）：

添加 64 个元素时：在 HashMap 中添加第 49 个元素时容量增加了一倍（128）（因为负载因子为 0.75）
添加 128 个元素时：在 HashMap 中添加第 97 个元素时容量增加了一倍（256）（也是因为负载因子为 0.75）。

将容量增加到64后，HashMap工作正常。

总的来说，bucket 使用链表到一定长度（8 个元素）。之后它使用树数据结构（容量有波动的地方）。原因是访问树结构（O（log（n）））比链表（O（n））快。

这张图片显示了一个 JAVA 8 HashMap 的内部数组，其中包含两个树（位于桶 0）和链表（位于桶 1,2 和 3）。 Bucket 0 是一棵树，因为它有超过 8 个节点 (readmore)。

Hashmap 上的文档和bucket in hashmap 上的讨论在这方面会有所帮助。

【讨论】：

是的，我的意思只是容量。编辑问题以更正它。令人困惑的是为什么哈希图在第 9 和第 10 个条目的容量翻了一番。为什么不在 13 号（应该根据文档）？ @JBNizet 已复制并在评论中提供了解释。我正在网上阅读更多内容以更好地理解。
我已经修改了我的答案。如有错误请告知
bucket 遵循 LinkedList 或 Tree 来存储 Map 条目。但是，该文档仅声明-“当哈希表中的条目数超过负载因子和当前容量的乘积时，对哈希表进行重新哈希（即重新构建内部数据结构），以便哈希表有大约两倍的桶数”。因此，尚不清楚它是根据哪些标准将其容量翻倍。
我已经根据 JB Nizet 的代码和我最近了解到的更多细节提供了我的答案。请检查答案
是的，没错。我还调试并发现方法“treeifyBin”在第 9 个和第 10 个条目被调用，这导致哈希图的容量加倍。之后，它就可以正常工作了。

【解决方案2】：

对 cmets 的回答比对问题本身的回答更多，因为您的 cmets 与您实际想知道的内容更相关。

where this rehashing on bucket size is explained further 的最佳和最相关的答案是源代码本身。您在 9-th 条目上观察到的内容是预期的，并且发生在这部分代码中：

for (int binCount = 0; ; ++binCount) {
    // some irrelevant lines skipped
    if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
        treeifyBin(tab, hash);
        break;
    }

其中TREEIFY_THRESHOLD = 8 和binCount 是垃圾箱的数量。

treeifyBin 方法名称有点误导，因为它可能会重新调整大小，而不是重新设置 bin，这是该方法代码的相关部分：

if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY)
        resize();

请注意，它实际上会 resize（读取其大小的两倍）并且在达到 MIN_TREEIFY_CAPACITY (64) 之前不会生成 Tree。

【讨论】：

【解决方案3】：

阅读hashmap的源码，

/**
 * The smallest table capacity for which bins may be treeified.
 * (Otherwise the table is resized if too many nodes in a bin.)
 * Should be at least 4 * TREEIFY_THRESHOLD to avoid conflicts
 * between resizing and treeification thresholds.
 */
static final int MIN_TREEIFY_CAPACITY = 64;

你会看到

如果容量没有达到 MIN_TREEIFY_CAPACITY(64)，并且单个桶上的节点达到 TREEIFY_THRESHOLD，现在 map 将调整大小。
如果容量超过MIN_TREEIFY_CAPACITY(64)，并且单个桶上的节点达到 TREEIFY_THRESHOLD，现在 map 将树化桶上的节点（源代码中的 bins）。

resize和treeify是两个可以带来map reorganize的操作，上面根据不同场景的决策也是一个权衡。

【讨论】：