hash表的容量与算法问题

chichenzhe 2013-10-21 03:05:24
hash表 如果以 hash.get(hashcode) 方式从一个数组里直接定位元素的话(假设无哈希碰撞发生)

那么 他这个 数组该是多大呢???

我们知道 hash散列算出的正整数值是很恐怖的一个大数, 至少得long去装吧. 这么恐怖的数量级, 如果要实现数组的话, 最小值 --> 最大值 相减所得到的跨度 应该超过数百万是不稀奇的吧?

那么, 也就是说 如果要实现一个仅有3个元素的hashtable, 你就得new一个 几百万个元素的数组去装载这3个元素. 并且将来add之后还有可能扩大这个跨度.
-----

如果不用这个跨度全覆盖的数组去做的话, 也还有办法,就是二分查找. 折半方式去找. 但这势必不是多了运算量么. 所以, 我想知道这个东西到底是什么情况.

因为我想,为了实现高速索引(不冲突情况下一击即中) 是不可能用掉这么恐怖的内存资源的. 但是详细的技术细节是什么呢, 往高手告知.
...全文
132 1 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
1 条回复
切换为时间正序
请发表友善的回复…
发表回复
gomoku 2013-10-21
  • 打赏
  • 举报
回复
通用的,完全不碰撞的hash表是不存在的。 碰撞的处理是hash表的基本功。由于hash码的限制,即使出现碰撞,实际使用搜索量也可以大幅度将减少。 这就像使用宿舍号码来作为学生的hash码,几个学生可以住同一个宿舍(hash碰撞),但用宿舍号来找人,已经极大地减少了搜索量。

111,095

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • AIGC Browser
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧