Object类中Hashcode和equals区别是什么

本篇内容介绍了“Object类中Hashcode和equals区别是什么”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

在衡东等地区,都构建了全面的区域性战略布局,加强发展的系统性、市场前瞻性、产品创新能力,以专注、极致的服务理念,为客户提供成都做网站、网站建设 网站设计制作按需求定制开发,公司网站建设,企业网站建设,成都品牌网站建设,全网营销推广,外贸网站制作,衡东网站建设费用合理。

equals Object 类中默认的实现方式是 : return this == obj 。那就是说,只有 this 和 obj 引用同一个对象,才会返回 true。Hashcode这个方法返回对象的散列码,返回值是 int 类型的散列码。

equals:


Object 类中默认的实现方式是 : return this == obj 。那就是说,只有 this 和 obj 引用同一个对象,才会返回 true。


而我们往往需要用 equals 来判断 2 个对象是否等价,而非验证他们的唯一性。这样我们在实现自己的类时,就要重写equals


按照约定,equals 要满足以下规则。


自反性: x.equals(x) 一定是 true


对 null: x.equals(null) 一定是 false


对称性: x.equals(y) 和 y.equals(x)结果一致


传递性: a 和 b equals , b 和 c equals,那么 a 和 c也一定 equals。


一致性: 在某个运行时期间,2 个对象的状态的改变不会影响 equals 的决策结果,那么,在这个运行时期间,无论调用多少次 equals,都返回相同的结果。


Hashcode:

     这个方法返回对象的散列码,返回值是 int 类型的散列码。


对象的散列码是为了更好的支持基于哈希机制的 Java 集合类,


例如 Hashtable, HashMap, HashSet 等。


关于 hashCode 方法,一致的约定是:


重写了 euqls 方法的对象必须同时重写 hashCode()方法。


如果 2 个对象通过 equals 调用后返回是 true,那么这个 2 对象的 hashCode 方法也必须返回同样的 int 型散列码


如果 2 个对象通过 equals 返回 false,他们的 hashCode 返回的值允许相同。(然而,程序员必须意识到,hashCode 返回一无二的散列码,会让存储这个对象的 hashtables 更好地作。)


在上面的例子中,Test 类对象有 2 个字段,num 和 data,这 2个字段代表了对象的状态,他们也用在 equals 方法中作为评判的依据。那么, 在 hashCode 方法中,这 2 个字段也要参与hash 值的运算,作为 hash 运算的中间参数。这点很关键,这是为了遵守:2 个对象 equals,那么 hashCode 一定相同规则。


也是说,参与 equals 函数的字段,也必须都参与 hashCode 的计算。


合乎情理的是:同一个类中的不同对象返回不同的散列码。典型的方式就是根据对象的地址来转换为此对象的散列码,但是这种方式对于 Java 来说并不是唯一的要求的的实现方式。通常也不是最好的实现方式。


相比 于 equals 公认实现约定,hashCode 的公约要求是很容易理解的。有 2 个重点是 hashCode 方法必须遵守的。约定的第 3点,其实就是第 2 点的细化,下面我们就来看看对 hashCode 方法的一致约定要求。


第一:在某个运行时期间,只要对象的(字段的)变化不会影响 equals 方法的决策结果,那么,在这个期间,无论调用多少次 hashCode,都必须返回同一个散列码。


第二:通过 equals 调用返回 true 的 2 个对象的 hashCode 一定一样。


第三:通过 equasl 返回 false 的 2 个对象的散列码不需要不同,也就是他们的 hashCode 方法的返回值允许出现相同的情况。


总结一句话:等价的(调用 equals 返回 true)对象必须产生相同的散列码。不等价的对象,不要求产生的散列码不相同。

“Object类中Hashcode和equals区别是什么”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!


网站标题:Object类中Hashcode和equals区别是什么
文章地址:http://scyanting.com/article/jpecpi.html