GC时对象地址变了，hashCode如何保持不变？

矫情吗；* 2022-11-16 15:22 321阅读 0赞

### 前言 ###

前几天跟朋友交流，引出了一篇文章《[GC复制存活对象，它内存地址变了么？][GC]》，我们得知在Hotspot虚拟机下，当GC发生时，对象的地址是会发生变化的。

同时我们也知道，无论何时调用同一对象的hashCode方法，都必须返回相同的值，也就是说一个对象的hashCode值要在生命周期中保持不变。同时，网传“hashCode是根据对象地址生成的”。那么，问题来了，当对象地址变化了，hashCode如何保持不变呢？

### HashCode的约定 ###

在继续研究之前，我们先来看一下对hashCode方法的一些约定和说明。

在java.lang.Object的JavaDoc注释上对hashCode方法有三项约定，概括来说就是：

第一，当一个对象equals方法所使用的字段不变时，多次调用hashCode方法的值应保持不变。

第二，如果两个对象equals(Object o)方法是相等的，则hashCode方法值必须相等。

第三，如果两个对象equals(Object o)方法是不相等，则hashCode方法值不要求相等，但在这种情况下尽量确保hashCode不同，以提升性能。

同时注释部分还有这样一段描述：

> As much as is reasonably practical, the hashCode method defined by class 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.)

通过上面的描述我们知道，一般情况下hashCode是通过对象的内存地址映射过来的。这也应该就是开篇说的“hashCode是根据对象地址生成的”的来源吧。

但我们知道，JVM进行GC操作时，无论是标记复制算法还是标记整理算法，对象的内存地址都是会变的。但hashcode又要求保持不变，JVM到底是如何实现这一功能的呢？另外还有一个问题，如果一个对象被移动到了另外一个位置，而它原来的位置被其他对象填充了，那新填充的对象是否会与之前的对象hashCode相同呢？

下面我们就来探究一下JVM的实现。

### GC前后的hashCode值 ###

我们先通过一个实例来验证一下GC前后对象地址和hashcode值的变化。在项目中引入JOL依赖：

<dependency>
        <groupId>org.openjdk.jol</groupId>
        <artifactId>jol-core</artifactId>
        <version>0.10</version>
    </dependency>

验证代码如下：

public class TestHashCode {
    
        public static void main(String[] args) {
            Object obj = new Object();
            long address = VM.current().addressOf(obj);
            long hashCode = obj.hashCode();
            System.out.println("before GC : The memory address is " + address);
            System.out.println("before GC : The hash code is " + hashCode);
    
            new Object();
            new Object();
            new Object();
    
            System.gc();
    
            long afterAddress = VM.current().addressOf(obj);
            long afterHashCode = obj.hashCode();
            System.out.println("after GC : The memory address is " + afterAddress);
            System.out.println("after GC : The hash code is " + afterHashCode);
            System.out.println("---------------------");
    
            System.out.println("memory address = " + (address == afterAddress));
            System.out.println("hash code = " + (hashCode == afterHashCode));
        }
    }

上述代码执环境为Hotspot虚拟机，执行时如果未出现GC，则可将JVM参数设置的小一点，比如可以设置为16M：-Xms16m -Xmx16m -XX:+PrintGCDetails。

执行上述代码，打印日志如下：

before GC : The memory address is 31856020608
    before GC : The hash code is 2065530879
    after GC : The memory address is 28991167544
    after GC : The hash code is 2065530879
    ---------------------
    memory address = false
    hash code = true

上面的控制台信息可以看出，GC前后对象的地址的确变了，但hashCode却并未发生变化。同时也可以看出hashcode的值与内存地址的值是完全不一样的，根据hashCode方法的注解，我们暂时只能认为hashcode值与地址有关。

### hashCode不变的原理 ###

经过上述实例，很明显在GC操作时，原来的hashcode值被存储在了某个地方，以备再用。对此以Hotspot为例，最直接的实现方式就是在对象的header区域中划分出来一部分（32位机器上是占用25位，64位机器上占用31）用来存储hashcode值。但这种方式会添加额外信息到对象中，而在大多数情况下hashCode方法并不会被调用，这就造成空间浪费。

那么JVM是如何进行优化的呢？当hashCode方法未被调用时，object header中用来存储hashcode的位置为0，只有当hashCode方法（本质上是System\#identityHashCode）首次被调用时，才会计算对应的hashcode值，并存储到object header中。当再次被调用时，则直接获取计算好hashcode即可。

上述实现方式就保证了即使GC发生，对象地址发生了变化，也不影响hashcode的值。比如在GC发生前调用了hashCode方法，hashcode值已经被存储，即使地址变了也没关系；在GC发生后调用hashCode方法更是如此。

### hashcode生成的方式 ###

不同的JVM对hashcode值的生成方式不同。Open JDK中提供了6中生成hash值的方法。

*  0：随机数生成器（A randomly generated number.）；
 *  1：通过对象内存地址的函数生成（A function of memory address of the object.）；
 *  2：硬编码1（用于敏感度测试）（A hardcoded 1 (used for sensitivity testing.)）；
 *  3：通过序列（A sequence.）；
 *  4：对象的内存地址，强制转换为int。（The memory address of the object, cast to int.）
 *  5：线程状态与xorshift结合（Thread state combined with xorshift）；

其中在OpenJDK6、7中使用的是随机数生成器的（第0种）方式，OpenJDK8、9则采用第5种作为默认的生成方式。所以，单纯从OpenJDK的实现来说，其实hashcode的生成与对象内存地址没有什么关系。而Object类中hashCode方法上的注释，很有可能是早期版本中使用到了第4种方式。

### hashCode与identityHashCode ###

上面我们多次提到hashCode方法，还提到identityHashCode方法，如果单纯以Object类中的hashCode方法来说，它与System类中提供了的identityHashCode方法是一致的。但在实践中我们往往会重写hashCode方法，此时object header中存储的hashcode值便有两种情况，一个是父类Object的，一个是实现类的。

在OpenJDK中，header中存储的是通过System\#identityHashCode获得的hashcode，而重写的hashCode方法的子类的hashcode则是通过实时调用其实现方法获得的。

那么，如果一个类的hashCode方法被重写了，那么是否还可以获得原始的hashcode吗？System\#identityHashCode方法可以返回一个不变的hascode值，无论当前对象是否重写了hashCode方法。

我们用一个实例来验证一下，先创建一个Person类，实现hashcode方法：

public class Person {
    
        private int id;
        // 省略getter/setter 和equals方法
    
        @Override
        public int hashCode() {
            return Objects.hash(id);
        }
    }

验证代码如下：

Person person = new Person();
    person.setId(1);
    
    System.out.println("Hashcode = " + person.hashCode());
    System.out.println("Identity Hashcode = " + System.identityHashCode(person));

执行验证程序，打印结果如下：

Hashcode = 32
    Identity Hashcode = 1259475182

会发现System\#identityHashCode方法采用了默认的hashCode方法，而不是Person对象重写的hashCode方法。本质上Object的hashCode方法也是调用的identityHashCode方法。

### 还有一个问题 ###

如果JVM使用基于对象内存地址的方式生成hashcode值，那么是否会出现这样的问题：如果Object1被调用了hashCode方法，然后GC移动。此时，Object2被分配到Object1原来的位置，Object2也调用hashCode方法，那么这两个对象的hashcode值是否相等呢？的确，它们有可能是相等的，但这也没什么关系，hashcode值只是一个hashcode值，并不要求它是唯一的。当出现hash冲突时，同样会出现相同的值。

### 再验证一下 ###

上面说了hashcode值的存储逻辑，那么是否可以从侧面证明一下呢？我们依旧采用JOL依赖类库，来写一个程序查看一下hashCode方法被调用之后，Object header中信息的变化。

// 创建对象并打印JVM中对象的信息
    Object person = new Object();
    System.out.println(ClassLayout.parseInstance(person).toPrintable());
    // 调用hashCode方法，如果重写了hashCode方法则调用System#identityHashCode方法
    System.out.println(person.hashCode());
    // System.out.println(System.identityHashCode(person));
    // 再次打印对象JVM中的信息
    System.out.println(ClassLayout.parseInstance(person).toPrintable());

执行上述程序，控制台打印如下：

java.lang.Object object internals:
     OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
          0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
          4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
          8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
         12     4        (loss due to the next object alignment)
    Instance size: 16 bytes
    Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
    
    1898220577
    java.lang.Object object internals:
     OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
          0     4        (object header)                           01 21 8c 24 (00000001 00100001 10001100 00100100) (613163265)
          4     4        (object header)                           71 00 00 00 (01110001 00000000 00000000 00000000) (113)
          8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
         12     4        (loss due to the next object alignment)
    Instance size: 16 bytes
    Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

在调用hashCode方法前后，我们可以看到OFFSET为0的一行存储的值（Value），从原来的1变为613163265，也就是说将hashcode的值进行了存储。如果未调用对应方法，则不会进行存储 。

### 小结 ###

经过本文的分析，我们会发现针对GC移动对象导致hashCode变化这个问题，在JVM未使用对象内存地址生成hashcode时已经不是什么问题了。但在探索这个问题的过程中，我们了解了hashcode的生成、存储以及与identityHashCode方法的关系，最后来实践了JOL的新用法，反而收获了更多。

--------------------

**程序新视界**  
公众号“ **程序新视界**”，一个让你软实力、硬技术同步提升的平台，提供海量资料

![微信公众号：程序新视界][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center]

[GC]: https://mp.weixin.qq.com/s/rKEdTxXIc8F8ZwGW-hTakg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center]: /images/20221022/41ca00931a734b3f836362e0ef6bb383.png

发表评论取消回复

表情：

评论列表（有 0 条评论，321人围观）

还没有评论，来说两句吧...

相关阅读

相关通过Canvas绘制线段时发现线变宽了颜色变淡了

背景在绘制线段时，发现设置的线段宽度为1像素和线段宽度为2像素的时，最终绘制出来的宽度大致一致，而且在没有设置画笔颜色的情况下，两条线段的颜色却不一样，详细参见以下示例

妖狐艹你老母/ 2022年11月18日 04:57/ 0 赞/ 127 阅读

相关 GC时对象地址变了，hashCode如何保持不变？

前言前几天跟朋友交流，引出了一篇文章《[GC复制存活对象，它内存地址变了么？][GC]》，我们得知在Hotspot虚拟机下，当GC发生时，对象的地址是会发生变化的。

矫情吗；*/ 2022年11月16日 15:22/ 0 赞/ 322 阅读

相关 GC复制存活对象，它内存地址变了么？

前些天与一位朋友技术交流，朋友在招人面试时想到一个问题，JVM垃圾回收时，会复制存活的对象到不同的区域。比如从新生代复制到老年代，在此过程中，被复制的对象的地址是否变了呢？对他

心已赠人/ 2022年11月16日 10:48/ 0 赞/ 166 阅读

相关 Git服务器地址变了本地怎么办

因为chrome浏览器屏蔽了10080端口，导致git不能在chrome上打开了，那就修改一下端口。本地还有一大批项目代码呢，若是都再下载一次，属实太费时费力了。怎么修改本

迷南。/ 2022年09月04日 04:53/ 0 赞/ 207 阅读

相关 JS实现页面跳转浏览器地址栏保持不变

JS实现页面跳转浏览器地址栏保持不变 -------------------- > 在公司内部框架中，发现点击超链接，页面发生跳转，而浏览器地址栏URL始终保持不变

谁借莪１个温暖的怀抱￠/ 2022年08月05日 13:12/ 0 赞/ 476 阅读

相关一不变应万变

计算机编程算是目前为止人类创造出来最复杂的东西了，把它分解到最小它就是0和1的各种组合。航天飞机、火箭、天宫二号…这些世界上最复杂的仪器，如果把他们都进行拆分到最后它们也

墨蓝/ 2022年07月14日 04:47/ 0 赞/ 206 阅读

相关 Kotlin的型变解析（协变、逆变和不变）

一、首先来看一个例子 import java.util. / @author:wangdong @description:型变 /

矫情吗；*/ 2022年05月28日 12:36/ 0 赞/ 287 阅读

相关 json字符串序列化后如何保持顺序不变

json字符串序列化后如何保持顺序不变使用阿里巴巴的fastjson对json字符串进行序列化，序列化之后发现顺序发生了改变，导致之后业务出现问题。解决方法：

淡淡的烟草味﹌/ 2022年03月25日 07:38/ 0 赞/ 835 阅读

相关 caffe训练时，loss一般出现87.3365则保持不变

caffe训练时，loss一般出现很奇怪的值：87.3365，则保持不变下去。直觉就有问题。 ![watermark_type_ZmFuZ3poZW5naGVpdGk_sha

比眉伴天荒/ 2022年03月20日 15:14/ 0 赞/ 188 阅读

相关刷新页面时 select、raido值保持不变

<select name="sex" id="sex" onchange="save()"> <option value="01" selected >

蔚落/ 2022年01月27日 12:21/ 0 赞/ 224 阅读