hash表的容量与算法问题
hash表 如果以 hash.get(hashcode) 方式从一个数组里直接定位元素的话(假设无哈希碰撞发生)

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

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

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

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

因为我想,为了实现高速索引(不冲突情况下一击即中) 是不可能用掉这么恐怖的内存资源的. 但是详细的技术细节是什么呢, 往高手告知.
------解决方案--------------------
通用的，完全不碰撞的hash表是不存在的。

碰撞的处理是hash表的基本功。由于hash码的限制，即使出现碰撞，实际使用搜索量也可以大幅度将减少。

这就像使用宿舍号码来作为学生的hash码，几个学生可以住同一个宿舍（hash碰撞），但用宿舍号来找人，已经极大地减少了搜索量。