为什么Java HashMap调整大小或重新哈希不能采用像Redis这样的渐进方法
我只是想知道为什么jdk HashMap的重排过程没有采用渐进的方法作为Redis。尽管Jdk HashMap的重新哈希计算非常优雅和有效，但是当原始HashMap中的元素数量包含许多条目时，仍然需要花费大量时间。我不是Java的经验丰富的用户，所以我始终认为必须考虑超出我的认知能力范围的Java设计人员。像Redis这样的渐进式哈希可以有效地将工作负载分配给HashMap中的每个放置，删除或获取，这可以显着减少调整大小/哈希的时间。而且我还比较了我认为不限制Jdk进行逐步重新哈希处理的两种哈希方法。希望有人可以提供线索或启发。非常感谢。
问题来源：Stack Overflow
展开
收起
1
条回答
写回答
写回答
-
如果考虑类似的增量重新哈希的成本和收益HashMap，事实证明这些成本并不是微不足道的，收益也不如您所愿。
逐步重新哈希HashMap：
- 平均使用50％以上的内存，因为它需要在增量重新哈希期间保留旧表和新表。
- 每次操作的计算成本较高。
- 重新哈希仍然不是完全增量的，因为分配新哈希表数组必须一次完成。
- 任何操作的渐进复杂性都没有改善。
- 由于无法预测的GC暂停，几乎完全不需要增量哈希的任何事情都可以在Java中实现，那么为什么要麻烦呢？
回答来源：Stack Overflow
2020-03-24 14:23:12赞同 展开评论 打赏
问答分类：
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
相关问答
