如您所述：
HashMap如JEP-180中所述，Java
8中的性能有了显着提高。基本上，如果哈希链超过一定大小，
HashMap则将（如果可能）将其替换为平衡的二叉树。这将导致各种操作的“最坏情况”行为，
O(logN)而不是
O(N)。
这并不能直接说明对的更改
hash。但是，我 假设
JEP-180中的优化意味着散列函数分布不均对性能造成的影响不那么重要，并且该方法的成本效益分析
hash有所变化。即，较复杂的版本 平均而言
受益较少。（束缚地说，当密钥类型的
hashpre方法生成高质量的代码时，那么复杂
hash方法中的体操将浪费时间。）
但这只是一个理论。进行
hash更改的真正理由很可能是Oracle机密。
