3回答

凌子祺

2020-03-03

感谢！解惑了。之前的疑问一直是，为什么在equals里面不直接return两个hashCode是否相等就可以。

在你这看到了解答。

0

0

_潇潇暮雨

2019-08-21

其实我感觉hashCode只有在存储hash表中会用到，从语言的设计角度来讲是不是应该向Compareable接口那样设计一个Hashable接口，而不是所有的类都有hashCode方法。

0

1

liuyubobobo

我个人认为这样设计也没有毛病：）但是，这样想下去，没完没了。比如 Object 默认也有 equals 方法，但是不是其实应该定义一个 Equalable 的接口呢？我觉得也没毛病。Java 选择对于这些方法，默认放置在 Object 中，如果你的对象不需要应用 hashCode，hashCode 这个方法也没有任何反面影响，也没有毛病。归根到底，这是一个设计问题。设计问题没有绝对的对与错：）

2019-08-22

共1条回复

liuyubobobo

2019-01-12

大赞！：）

感谢分享：）

继续加油！：）

0

5

liuyubobobo

回复

凌子祺

了解了。其实，如果能严谨地按照进制的方式定下来 B 最好，比如如果字符串的取值范围就是 26 个字母，B 取 26 肯定没有问题。但是，如果数据的取值范围特别随意的话，B 按照严谨的进制取值，就会造成哈希结果极度稀疏。比如对于日期，年份假定最大是 9999，此时，B 取 10000 是最合理的，但是这样做，哈希值的范围太大了。这种情况，适当缩小 B 的值，严格来说，这个数据不是一个 B 进制的数，但此时只是多了哈希冲突而已，不影响我们逻辑的正确性。 举个例子，假设十进制的数字，但是我们的 B = 5，会发生什么？此时 【81】这个表示的哈希值等于41（8*5+1），而【76】这个表示的哈希值也是41【7*5+6】，所以，【81】和【76】哈希冲突了。但是如果 B = 10，不会出现这样的哈希冲突。 因此，B 的大小，是在调节哈希值的范围和哈希冲突出现的频率。B 越大，哈希值的范围越广，冲突出现的概率越小；B 越小，哈希值的范围约窄，但冲突出现的概率也越高。我们需要根据自己的数据，选择合适的 B。继续加油！：）

2020-03-04

共5条回复