equals方法
public boolean equals(Object obj) {
return (this == obj);
}
比较两个对象的地址值进行的比较(即比较引用是否相同)。但String 、Math、Integer、Double等这些封装类重写了equals方法。只比较值。
equals四个性质:
-
自反性
-
对称性
-
传递性
-
一致性
hashcode方法
一个函数,给对象返回一个hashcode值,不同的对象的hashcode计算的值不一样,当两个对象equals返回true,那hashcode值也一样,反之不一定。
object类中,hashCode定义,本地方法,返回的是对象的地址值。(通过这个地址可以计算出对象在hash表中的位置)
public native int hashCode();
同样String、Integer、Double等这些类也都重写了hashcode方法
public int hashCode() {
int h = hash;
if (h == 0) {
int off = offset;
char val[] = value;
int len = count;
for (int i = 0; i < len; i++) {
h = 31 * h + val[off++];
}
hash = h;
}
return h;
}
为啥乘31,原因1,31*i==(i<<5)-i .通过移位和减法代替乘法,jvm会自动完成这个优化。2.使用较小的素数,比如2,冲突率会很高,使用31,34,37等算出来的哈希值冲突都小于7个。那为啥不选择101这种,乘数过大会导致哈希值溢出。
hashcode的存在主要是为了提高查找效率。通过hashcode找到对应在hash表中的位置,不用全部比,减少比较次数。
相等(相同)的对象必须具有相等的哈希码(或者散列码),为什么?
想象一下,假如两个Java对象A和B,A和B相等(eqauls结果为true),但A和B的哈希码不同,则A和B存入HashMap时的哈希码计算得到的HashMap内部数组位置索引可能不同,那么A和B很有可能允许同时存入HashMap,显然相等/相同的元素是不允许同时存入HashMap,HashMap不允许存放重复元素。
两个对象的hashCode相同,它们并不一定相同
也就是说,不同对象的hashCode可能相同;假如两个Java对象A和B,A和B不相等(eqauls结果为false),但A和B的哈希码相等,将A和B都存入HashMap时会发生哈希冲突,也就是A和B存放在HashMap内部数组的位置索引相同这时HashMap会在该位置建立一个链接表,将A和B串起来放在该位置,显然,该情况不违反HashMap的使用原则,是允许的。当然,哈希冲突越少越好,尽量采用好的哈希算法以避免哈希冲突。
所以,Java对于eqauls方法和hashCode方法是这样规定的:
1.如果两个对象相同,那么它们的hashCode值一定要相同;
2.如果两个对象的hashCode相同,它们并不一定相同(这里说的对象相同指的是用eqauls方法比较)。
如不按要求去做了,会发现相同的对象可以出现在Set集合中,同时,增加新元素的效率会大大下降。
3.equals()相等的两个对象,hashcode()一定相等;equals()不相等的两个对象,却并不能证明他们的hashcode()不相等。
换句话说,equals()方法不相等的两个对象,hashcode()有可能相等(我的理解是由于哈希码在生成的时候产生冲突造成的)。反过来,hashcode()不等,一定能推出equals()也不等;hashcode()相等,equals()可能相等,也可能不等。
(String 都重写了这两个方法,不会有以下问题)
重写了equals方法,却没有重写hashcode方法,两个对象equals会返回true,但两个对象的.hashcode会不一样。这样就会存在一个问题,
如果现在把这两个对象存到hashset 或hashmap中去,会先调用对象的hashcode方法,根据值找到此对象在hash表中的位置,hashcode不一样,存储的位置也不一样,最常见的问题导致两个对象无法去重,虽然equals返回true,还是会当作两个不同的对象
重写hashcode方法,却没有重写equals方法,
不重写equals,去重的时候,removeAll,底层实现还是equals,比地址,比引用,依旧无法去重,依旧还是两个对象。