重写 hashcode()真有那么简单嘛?

万万没想到一个 hashcode() 方法,既然会引出一堆的知识盲区,简直了。

起因:

老八股:为什么重写Equals方法要重写HashCode方法。

大声告诉我为什么,闭着眼睛先把答案背出来,啥?这都忘了?没事,也不是啥大事。这两句话再Object类的 hashcode 中的注释上就有,但是一般八股文不会告诉你是出自这里的。凝聚成两句话就是:

1 如果两个对象通过equals()方法比较相等,那么这两个对象的hashCode一定相同。

2 如果两个对象hashCode相同,不能证明两个对象是同一个对象(不一定相等),只能证明两个对象在散列结构中存储在同一个地址(不同对象hashCode相同的情况称为hash冲突)。

  • 标准嘛,很标准,但是还不够,一般人到这里已经结束了,但是我还想和面试官在掰扯一下:从Object类中 hashcode 的注释上就写着很明白了,具体如下
    /**
     * Returns a hash code value for the object. This method is
     * supported for the benefit of hash tables such as those provided by
     * {@link java.util.HashMap}.
     * 
     * The general contract of {@code hashCode} is:
     * 
    *
  • Whenever it is invoked on the same object more than once during * an execution of a Java application, the {@code hashCode} method * must consistently return the same integer, provided no information * used in {@code equals} comparisons on the object is modified. * This integer need not remain consistent from one execution of an * application to another execution of the same application. *
  • If two objects are equal according to the {@code equals(Object)} * method, then calling the {@code hashCode} method on each of * the two objects must produce the same integer result. *
  • It is not required that if two objects are unequal * according to the {@link java.lang.Object#equals(java.lang.Object)} * method, then calling the {@code hashCode} method on each of the * two objects must produce distinct integer results. However, the * programmer should be aware that producing distinct integer results * for unequal objects may improve the performance of hash tables. *
* * As much as is reasonably practical, the hashCode method defined by * class {@code Object} does return distinct integers for distinct * objects. (This is typically implemented by converting the internal * address of the object into an integer, but this implementation * technique is not required by the * Java™ programming language.) * * @return a hash code value for this object. * @see java.lang.Object#equals(java.lang.Object) * @see java.lang.System#identityHashCode */ public native int hashCode();

  • 看着很长,其实不然,给你们翻译一下第一句话---什么叫中式翻译,如下

Returns a hash code value for the object. This method is supported for the benefit of hash tables such as those provided by

返回 一个 hash code 值 为 这个 对象。这个 方法 是 支持 的 这个 好处 体现为 hash 表 比如 这些 提供的 {@link java.util.HashMap}.


权威解释

什么乱七八糟的,还是来看看比较权威的。

  • Effective Java 第三版 中 描述为什么重写equals 方法后必须重写hashCode 方法

每个覆盖了equals方法的类中,必须覆盖hashCode。如果不这么做,就违背了hashCode的通用约定,也就是上面注释中所说的。进而导致该类无法结合所以与散列的集合一起正常运作,这里指的是HashMap、HashSet、HashTable、ConcurrentHashMap。

提炼:如果重写equals不重写hashCode它与散列集合无法正常工作。

总结:恍然大悟,原来是这样,那我这个对象,不存在这些散列集合中不就不用遵守这个规则了嘛。哈哈,大聪明,理论上确实是这样。但是这篇文章我还想再写长一些,多占用一些面试时间,毕竟我还有主动权机会。

hashcode()”伪源码“

  • 首先声明一点:Object 提供的 hashCode() 方法返回值是不会重复的(也就是说每个对象返回的值都不一样)。

有人说,扯淡嘛,我看了Object类中的hashcode()方法,里面什么也没有啊,只有方法,没看到实现,哪里来的返回值呢。

public native int hashCode();

关键字 native

首先看到看关键字 native,知识盲区来了,很多人不知道 这是啥东西,当然,说起这个,就要从盘古开天辟地开始讲了,我们这一节也不着重讲这个,篇幅有限,感兴趣的去问问度娘吧。

  • 先看概念:
native 用来修饰方法,用 native 声明的方法表示告知 JVM 调用,该方法在外部定义,我们可以用任何语言去实现它。简单地讲,一个native Method就是一个 Java 调用非 Java 代码的接口。
  • 简单来说:我们在日常编程中看到native修饰的方法,只需要知道这个方法的作用是什么,至于别的就不用管了,操作系统会给我们实现。

原来是这样,要是我写的代码也能这样就好了,我就写个方法,用 native 修饰,然后操作系统就给我自动实现。

想的美了,其实操作给我们实现,也是其他程序员写好的代码提前编译好了,换句话来说就是:哪有岁月静好,只是有猿替你负重前行罢了。

  • 作为一个Java程序员,我们还是想了解一些底层JDK代码的。所以,必须把源码扒出来,哪怕看不懂。(这是openjdk中的源码)。

JDK目录

  • 知识盲区,有一说一,能把 JDK 源码读懂的人,真大神也。
openjdk
├ corba:不流行的多语言、分布式通讯接口
├ hotspot:Java 虚拟机
├ jaxp:XML 处理
├ jaxws:一组 XML web services 的 Java API
├ jdk:java 开发工具包
├ langtools:Java 语言工具
└ nashorn:JVM 上的 JavaScript 运行时

hotspot目录

  • 什么叫源码,什么叫底层,这就叫专业!!!
hotspot
├─agent                            Serviceability Agent的客户端实现
├─make                             用来build出HotSpot的各种配置文件
├─src                              HotSpot VM的源代码
│  ├─cpu                            CPU相关代码(汇编器、模板解释器、ad文件、部分runtime函数在这里实现)
│  ├─os                             操作系相关代码
│  ├─os_cpu                         操作系统+CPU的组合相关的代码
│  └─share                          平台无关的共通代码
│      ├─tools                        工具
│      │  ├─hsdis                      反汇编插件
│      │  ├─IdealGraphVisualizer       将server编译器的中间代码可视化的工具
│      │  ├─launcher                   启动程序“java”
│      │  ├─LogCompilation             将-XX:+LogCompilation输出的日志(hotspot.log)整理成更容易阅读的格式的工具
│      │  └─ProjectCreator             生成Visual Studio的project文件的工具
│      └─vm                           HotSpot VM的核心代码
│          ├─adlc                       平台描述文件(上面的cpu或os_cpu里的*.ad文件)的编译器
│          ├─asm                        汇编器接口
│          ├─c1                         client编译器(又称“C1”)
│          ├─ci                         动态编译器的公共服务/从动态编译器到VM的接口
│          ├─classfile                  类文件的处理(包括类加载和系统符号表等)
│          ├─code                       动态生成的代码的管理
│          ├─compiler                   从VM调用动态编译器的接口
│          ├─gc_implementation          GC的实现
│          │  ├─concurrentMarkSweep      Concurrent Mark Sweep GC的实现
│          │  ├─g1                       Garbage-First GC的实现(不使用老的分代式GC框架)
│          │  ├─parallelScavenge         ParallelScavenge GC的实现(server VM默认,不使用老的分代式GC框架)
│          │  ├─parNew                   ParNew GC的实现
│          │  └─shared                   GC的共通实现
│          ├─gc_interface               GC的接口
│          ├─interpreter                解释器,包括“模板解释器”(官方版在用)和“C++解释器”(官方版不在用)
│          ├─libadt                     一些抽象数据结构
│          ├─memory                     内存管理相关(老的分代式GC框架也在这里)
│          ├─oops                       HotSpot VM的对象系统的实现
│          ├─opto                       server编译器(又称“C2”或“Opto”)
│          ├─prims                      HotSpot VM的对外接口,包括部分标准库的native部分和JVMTI实现
│          ├─runtime                    运行时支持库(包括线程管理、编译器调度、锁、反射等)
│          ├─services                   主要是用来支持JMX之类的管理功能的接口
│          ├─shark                      基于LLVM的JIT编译器(官方版里没有使用)
│          └─utilities                  一些基本的工具类
└─test                             单元测试

hashcode() 真源码

  • 在openjdk8根路径/hotspot/src/share/vm/runtime路径下的synchronizer.cpp文件中,有生成哈希值的代码:
static inline intptr_t get_next_hash(Thread * Self, oop obj) {
  intptr_t value = 0 ;
  if (hashCode == 0) {
     // 返回随机数
     value = os::random() ;
  } else
  if (hashCode == 1) {
     //用对象的内存地址根据某种算法进行计算
     intptr_t addrBits = cast_from_oop(obj) >> 3 ;
     value = addrBits ^ (addrBits >> 5) ^ GVars.stwRandom ;
  } else
  if (hashCode == 2) {
     // 始终返回1,用于测试
     value = 1 ;            
  } else
  if (hashCode == 3) {
     //从0开始计算哈希值
     value = ++GVars.hcSequence ;
  } else
  if (hashCode == 4) {
     //输出对象的内存地址
     value = cast_from_oop(obj) ;
  } else {
     // 默认的hashCode生成算法,利用xor-shift算法产生伪随机数
     unsigned t = Self->_hashStateX ;
     t ^= (t _hashStateX = Self->_hashStateY ;
     Self->_hashStateY = Self->_hashStateZ ;
     Self->_hashStateZ = Self->_hashStateW ;
     unsigned v = Self->_hashStateW ;
     v = (v ^ (v >> 19)) ^ (t ^ (t >> 8)) ;
     Self->_hashStateW = v ;
     value = v ;
  }

  value &= markOopDesc::hash_mask;
  if (value == 0) value = 0xBAD ;
  assert (value != markOopDesc::no_hash, "invariant") ;
  TEVENT (hashCode: GENERATE) ;
  return value;
}

先上一首凉凉。不是看不懂啊,毕竟大学学过C,但是脑瓜子嗡嗡的,肯定不能专研这个了,先跳过,回到正题。

为什么要重写hashcode我们大概知道了,那如果我偏不重写呢,先来个铁头娃demo看看效果。

    public class Person {
        //用户Id,唯一确定用户
        private String id;
        private String name;

        public Person(String id, String name) {
            this.id = id;
            this.name = name;
        }

        @Override
        public boolean equals(Object o) {
            if (this == o) return true;
            if (!(o instanceof Person)) return false;
            Person person = (Person) o;
            return Objects.equals(id, person.id) && Objects.equals(name, person.name);
        }

        public String getId() {
            return id;
        }

        public void setId(String id) {
            this.id = id;
        }

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }
    }

    @Test
    public void test() {
        HashMap map = new HashMap();
        //key:Person类型  value:Integer类型
        Person personKey = new Person("1","张三");
        Person getKey = new Person("1","张三");
        map.put(personKey,100);
        System.out.println("原对象map.get():"+map.get(personKey));
        System.out.println("值相同的对象map.get():"+map.get(getKey));
    }

输出结果:

-------测试前准备-创建对象-------
原对象map.get():100
值相同的对象map.get():null
-------测试结束-------

这里我们很明显看到,我们要用之前的对象才能从HashMap中获取到key。这不是我们想要的效果啊,再也不头铁了。


  • 这时有人就会说了,那我用之前的对象不就好了嘛,干嘛要new个新的对象呢?其实这也是demo和实际项目的差距。如果你做过项目的就知道,我们的实体类每次请求进来都是个新的对象,最最最不济,你什么PO转DO,DO转DTO不就是要创建新的对象嘛。

呐呐呐,问题又来了,我不用Map不就行了,可以。当然可以,但是现在的项目里面,如果说整个项目没有用到Map的,那这个项目估计也不叫项目了,写java的人,谁能拒绝来个Map呢。

  • OK,最后啊,这hashcode()方法到底应该怎么写呢,这也头大啊,一个hashcode()咋就那么难呢,来来来思考两分钟,你想好怎么写了嘛。先别说,我把前提撩在这,你在仔细想想。一个是 ”相同的对象“ 的 hashcode() 要相同,不同对象的 hashcode() 不能相同。比如 :
        Person key = new Person("1","张三");
        Person sameKey = new Person("1","张三");
        Person unSameKey = new Person("2","张三");

其中 key 和 sameKey 的 hashcode()一定要相同,因为我们的业务员就是认为他们应该是相同的。但是同时 unSame 和 key 的 hashcode() 一定不能相同。

  • 这个时候,使用Object的 hashcode() 很显然就是不行了,应为它返回每个对象的 hashcode() 都是不相同的。
  • 当然了,所有 hashcode() 都返回 0 ,这也不是不行,只是违背了这句话:如果两个对象hashCode相同,不能证明两个对象是同一个对象(不一定相等)。

来吧,开始发散思维。

方法一:

  • 使用String 的hashcode(),你对象里面的属性不是String 类型嘛,String 里面已经重写了 hashcod() 方法那我直接用现成的就好了。
        @Override
        public int hashCode() {
            return  id.hashCode() + name.hashCode();
        }

但是我们还是要从各个角度出发去想一下的,比如判空,是否会值溢出之类的,这里我们也参考String 的 hashcode() 套娃一个。优化后:

        @Override
        public int hashCode() {
            //初始值,别问为什么是 17, 因为我写 18 你也会这样问的
            int result = 17;
            // 31 作为基数,不知道啊,String 里面 的 hashcode() 就是写的 31
            result = 31 * result + (id == null ? 0 : id.hashCode());
            result = 31 * result + (name == null ? 0 : name.hashCode());
            return result;
        }

方法二:

  • 调用JDK提供好的Objects里面的hashcode()
 @Override
    public int hashCode() {
        return Objects.hash(id,name);
    }

看了这两个方法,没错,这都是站在巨人的肩膀上。其实要是自己动手实现,那难度就直线上升了,至少算法这一块要啃一下。

hashcode() 方重写规则

写hashcode()要遵循以下原则:

equals不相等时并不强制要求哈希值相等,但是一个优秀的哈希算法应尽可能让元素均匀分布,降低冲突发生的概率,即在equals不相等时尽量让哈希值也不相等,这样&&或||短路操作一旦生效,会极大提高程序的效率。

重写equals都是根据业务需求去进行重写的,想想为什么String是这么判断两个字符串对象相等的。如果抛开业务需求谈这个,就是耍流氓。但是大多数情况下,都是不用重写 equals() 和 hashcode() 的,就是因为有了特殊的业务逻辑,所以我们才需要重写里面的逻辑。

知识盲区

不想写了, 今天就先结束吧,呼应一下开头,看看都涉及到哪些知识点,下次再遇到这样的八股文,一开口就能聊几个小时。

1、hashcode() 方法是 native 关键字修饰的,你有了解过嘛、Java方法和本地方法有什么不同、为什么要注册本地方法呢?

2、Object类中并没有hashcode() 方法源码,真正的源码应该去哪里看

3、jdk 源码目录,你真正打开过jdk源码嘛

4、 hashcode() 源码上有 @see java.lang.System#identityHashCode。那你知道 这两个方法有什么区别嘛

5、hashcode() 方法一定要重写,强调的是和hash表相关,那你知道源码中都是这么体现的嘛

6、hashcode() 手写实现,需要有什么功底呢?

7、调用了 String 的 hashcode() 去实现,那你知道 String#hashcode() 中为什么要用常数 31 嘛

8、如果不从写 hashcode() 会发生什么呢

9、Objects#hash()实现和 String 的 hashcode() 有什么异同呢

10、hashmap 中的 hash算法和 hashcode 有什么关系呢,hahscode会不会影响到 hash算法的结果?

11、如果hashcode() 每次返回的数是一个随机数,会发生什么。

12、为什么先比较 hashcode() 在比较 equlas能提高效率呢?List 集合比较的弊端、Map key 实现的优势

文章来源于互联网:重写 hashcode()真有那么简单嘛?

THE END
分享
二维码