为什么重写equals方法还要重写hashcode方法?
我们都知道Java语言是完全面向对象的,在java中,所有的对象都是继承于Object类。Ojbect类中有两个方法equals、hashCode,这两个方法都是用来比较两个对象是否相等的。
在未重写equals方法我们是继承了object的equals方法,那里的 equals是比较两个对象的内存地址,显然我们new了2个对象内存地址肯定不一样
- 对于值对象,==比较的是两个对象的值
- 对于引用对象,比较的是两个对象的地址
默认的equals方法同==,一般来说我们的对象都是引用对象,要重写equals方法。
现在有一个学生对象,有属性学号跟姓名,现在我新建了一个学生对象,又从数据里查出一个学生对象,这两个对象的学号跟姓名都一样,那这两个对象是不是相等呢?一般情况下,除非你有特殊需求要处理,这两个对象是相等的,可如果用==去比较,返回的结果是错误的。
这时候我们就必须重写equlas方法了。如果学号是主键,在equals方法里,我们认为只要学号相同,就可以返回true。
hashCode方法也是可以用来比较两个对象是否相等的。但是我们很少使用,应该说是很少直接使用。hashCode方法返回的是一个int值,可以看做是一个对象的唯一编码,如果两个对象的hashCode值相同,我们应该认为这两个对象是同一个对象。
一般如果使用java中的Map对象进行存储时,他会自动调用hashCode方法来比较两个对象是否相等。
所以如果我们对equals方法进行了重写,建议一定要对hashCode方法重写,以保证相同的对象返回相同的hash值,不同的对象返回不同的hash值。
如上面的学生例子,如果学号相同,不管姓名相不相同,返回的hash值一定要是一样的,这时我们的hash值只与学号有关。
public class Test
{
public static void main(String[] args)
{
HashMap hm = new HashMap(); hm.put(new key(1),new value(2));
if(hm.containsKey(new key(1)))
System.out.println(hm.get(new key(1)));
else
System.out.println("dont have such a key");
}
}
你每次new 一个新对象出来hashcode肯定不一样,所以你拿不到你要的key。
class key
{
int i ;
public key(int i)
{
this.i = i;
}
@Override
public boolean equals(Object obj)
{
if(obj instanceof key)
{
if(((key)obj).i == i)
return true;
}
return false;
}
@Override
public int hashCode()
{
return i;
}
}
1、重写equals方法时需要重写hashCode方法,主要是针对Map、Set等集合类型的使用;
a: Map、Set等集合类型存放的对象必须是唯一的;
b: 集合类判断两个对象是否相等,是先判断equals是否相等,如果equals返回TRUE,还要再判断HashCode返回值是否ture,只有两者都返回ture,才认为该两个对象是相等的。
2、由于Object的hashCode返回的是对象的hash值,所以即使equals返回TRUE,集合也可能判定两个对象不等,所以必须重写hashCode方法,以保证当equals返回TRUE时,hashCode也返回Ture,这样才能使得集合中存放的对象唯一。
为什么重写equals方法还要重写hashcode方法?的更多相关文章
- 为什么重写equals时必须重写hashCode方法?(转发+整理)
为什么重写equals时必须重写hashCode方法? 原文地址:http://www.cnblogs.com/shenliang123/archive/2012/04/16/2452206.html ...
- 讲解:为什么重写equals时必须重写hashCode方法
一 :string类型的==和equals的区别: 结论:"=="是判断两个字符串的内存地址是否相等,equals是比较两个字符串的值是否相等,具体就不做扩展了,有兴趣的同学可以去 ...
- 为什么重写equals一定要重写hashCode方法?
大家都知道,equals和hashcode是java.lang.Object类的两个重要的方法,在实际应用中常常需要重写这两个方法,但至于为什么重写这两个方法很多人都搞不明白. 下面我们看下Objec ...
- 为什么重写equals一定要重写hashCode?
大家都知道,equals和hashcode是java.lang.Object类的两个重要的方法,在实际应用中常常需要重写这两个方法,但至于为什么重写这两个方法很多人都搞不明白,以下是我的一些个人理解. ...
- 为什么重写equals后要重写hashCode
equals和hashCode的关系 要搞清楚题目中的问题就必须搞明白equals方法和hashCode方法分别是什么,和诞生的原因,当搞明白了这一点其实题目就不算是个问题了,下面我们来探讨分别探讨一 ...
- java 中为什么重写 equals 后需要重写 hashCode
本文为博主原创,未经允许不得转载: 1. equals 和 hashCode 方法之间的关系 这两个方法都是 Object 的方法,意味着 若一个对象在没有重写 这两个方法时,都会默认采用 Objec ...
- 编写高质量代码改善C#程序的157个建议——建议12: 重写Equals时也要重写GetHashCode
建议12: 重写Equals时也要重写GetHashCode 除非考虑到自定义类型会被用作基于散列的集合的键值:否则,不建议重写Equals方法,因为这会带来一系列的问题. 如果编译上一个建议中的Pe ...
- 为什么重写equals时必须重写hashCode方法?
原文地址:http://www.cnblogs.com/shenliang123/archive/2012/04/16/2452206.html 首先我们先来看下String类的源码:可以发现Stri ...
- java中为什么重写equals时必须重写hashCode方法?
在上一篇博文Java中equals和==的区别中介绍了Object类的equals方法,并且也介绍了我们可在重写equals方法,本章我们来说一下为什么重写equals方法的时候也要重写hashCod ...
随机推荐
- SQL 面试题(一)
问题来自于CSDN问答,练练SQL吧. 测试数据SQL代码: if OBJECT_ID('td_ls_2') is not null drop table td_ls_2 go if OBJECT_I ...
- table的边框线的设置
http://hi.baidu.com/weisuotang/item/a1d98ec298c0aa49a8ba9447 http://www.cnblogs.com/xinlei/archive/2 ...
- EHCache 实现通用类 CacheManager
package com.zhubaje.api.workflow.ehcache; import java.io.Serializable; import java.util.ArrayList; i ...
- orcale 修改字段属性
有些时候,因为没能预料到一些情况的变化,需要修改字段的类型.如果是varchar型,直接增加长度是可以的,但是如果需要修改成其他类型就不能这么做了. 思路:1.增加一个临时列,把需要修改的那个字段的数 ...
- Rac & DG
Rac环境: RAC版本异同:[10R2,11R1(和10类似)],11R2,12c: 目录: 10.2的ASM需要单独的目录(oracle home):rdbms home,asm home, cr ...
- C++中的冒泡排序,选择排序,插入排序
最简单的插入排序:思想,两两之间比较,时间复杂度o(n^2) void bubblesort(vector<int>&vec, int n) { if (&vec==NUL ...
- Laravel5 路由问题 /home页面无法访问
参考网址:http://stackoverflow.com/questions/11791375/laravel-routes-not-working Laravel5 路由问题 /home页面无法访 ...
- iOS 23 种设计模式
设计模式主要分三个类型:创建型.结构型和行为型. 其中创建型有: 一.Singleton,单例模式:保证一个类只有一个实例,并提供一个访问它的全局访问点 二.Abstract Factory,抽象工厂 ...
- Jquery datatables 重载数据方法
参考这里 { RefreshTable('#table-example', '/BlogManage/GetLabelData'); } function RefreshTable(tableId, ...
- Ubuntu 查看文件以及磁盘空间大小命令df
(1)查看文件大小 查看当前文件夹下所有文件大小(包括子文件夹) du -sh # du -h 15M ./package 16K ./.fontconfig 4.0K ...