口往往会面临很多次请求，我们来解释一下幂等的概。
前几天跟朋友交流，引出了一篇文章《[GC复制存活对象，它内存地址变了么？] 》，我们得知在Hotspot虚拟机下，当GC发生时，对象的地址是会发生变化的。
同时我们也知道，无论何时调用同一对象的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值的变化。在项目中引入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值与地址有关。
经过上述实例，很明显在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方法更是如此。
不同的JVM对hashcode值的生成方式不同。Open JDK中提供了6中生成hash值的方法。
其中在OpenJDK6、7中使用的是随机数生成器的（第0种）方式，OpenJDK8、9则采用第5种作为默认的生成方式。所以，单纯从OpenJDK的实现来说，其实hashcode的生成与对象内存地址没有什么关系。而Object类中hashCode方法上的注释，很有可能是早期版本中使用到了第4种方式。
上面我们多次提到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的新用法，反而收获了更多。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8