为什么 Java 8 中的哈希映射使用二叉树而不是链表？ [关闭]

Question

我最近了解到，在 Java 8 中，哈希映射使用二叉树而不是链表，并且哈希码用作分支因子。我知道在发生高冲突的情况下，查找从 O(log n) 减少到O(n) 通过使用二叉树。我的问题是它真的有什么好处，因为摊销时间复杂度仍然是 O(1)，也许如果你通过提供相同的哈希码来强制将所有条目存储在同一个桶中我们可以看到所有键都存在显着的时差，但没有人会这样做。

二叉树也比单链表使用更多的空间，因为它同时存储了左右节点。除了一些虚假的测试用例之外，时间复杂度绝对没有改善，为什么还要增加空间复杂度。

Answer 1

这主要是与安全相关的更改。虽然在正常情况下很少可能发生多次冲突，但如果哈希键来自不受信任的来源（例如，从客户端接收的 HTTP 标头名称），那么特制输入是可能的并且不是很难，因此生成的键将具有相同的哈希码。现在，如果您执行许多查找，您可能会遇到拒绝服务。看起来有相当多的代码很容易受到这种攻击，因此决定在 Java 端解决这个问题。

更多信息请参考JEP-180。

Answer 2

您的问题包含一些错误的前提。

1. 桶冲突不一定是哈希冲突。您不需要为两个对象使用相同的哈希码就可以在同一个存储桶中结束。桶是数组的一个元素，哈希码必须映射到特定的索引。由于数组大小相对于Map 的大小应该是合理的，因此您不能随意提高数组大小以避免桶冲突。甚至存在理论上的限制，即数组大小最大为 2³¹，而可能的哈希码为 2³²。
2. 发生哈希冲突并不表示编程不当。对于所有值空间大于 2³² 的对象，具有相同哈希码的不同对象的可能性是不可避免的。 Strings 是一个明显的例子，但即使是带有两个 int 值的 Point 或普通的 Long 键也会不可避免地发生哈希冲突。因此它们可能比您想象的更常见，这在很大程度上取决于用例。
3. 仅当存储桶中的冲突数量超过某个阈值时，实施才会切换到二叉树，因此更高的内存成本仅适用于它们将得到回报的情况。关于它们的工作方式，似乎存在一个普遍的误解。由于桶冲突不一定是哈希冲突，所以二分查找会首先搜索哈希码。只有当哈希码相同并且密钥适当地实现Comparable时，才会使用其自然顺序。您可能在 Web 上找到的示例故意使用相同的对象哈希码来演示 Comparable 实现的使用，否则不会出现。他们触发的只是实施的最后手段。
4. 作为Tagir pointed out，此问题可能会影响软件的安全性，因为缓慢的回退可能会打开 DoS 攻击的可能性。在以前的 JRE 版本中已经多次尝试解决这个问题，但这些问题比二叉树的内存消耗有更多的缺点。例如，在 Java 7 中尝试将哈希码随机映射到数组条目，这导致了 this bug report 中记录的初始化开销。新的实现并非如此。