java - 为什么Java HashMap调整大小或重新哈希不能采用像Redis这样的渐进方法

Question

我只是想知道为什么jdk HashMap的重排过程没有采用渐进的方法作为Redis。尽管Jdk HashMap的重新哈希计算非常优雅和有效，但是当原始HashMap中的元素数量包含大量条目时，仍需要花费大量时间。
我不是Java的经验丰富的用户，因此我始终认为必须考虑超出我的认知能力范围的Java设计人员。
像Redis这样的渐进式哈希可以有效地将工作负载分配给HashMap中的每个放置，删除或获取，这可以显着减少调整大小/哈希的时间。
而且我还比较了两种哈希方法，这些方法在我看来并不限制Jdk进行渐进式哈希。
希望有人可以提供线索或启发。非常感谢。

Answer 1

如果考虑诸如HashMap之类的增量重新哈希的成本和 yield ，事实证明这些成本并不是微不足道的， yield 也不如您所愿。

重新哈希表HashMap:

平均使用50％以上的内存，因为在增量重新哈希期间，它需要同时保留旧表和新表。和

每个操作的计算成本较高。另外:

重新哈希仍然不是完全增量的，因为分配新哈希表数组必须一次完成。所以

任何操作的渐近复杂性都没有改善。最后:

由于不可预测的GC暂停，几乎完全不需要增量哈希的任何内容都可以在Java中实现，那么为什么要麻烦呢？