How does hashCode stay the same when the object address changes during GC?

Before we continue, let’s look at some conventions and instructions for the hashCode method.

There are three conventions for hashCode methods on JavaDoc annotations for java.lang.Object, which can be summarized as follows:

First, the value of multiple calls to the hashCode method should remain the same when the fields used by the equals method of an object are unchanged.

Second, if two objects are equal to their equals(Object O) methods, the hashCode method values must be equal.

Third, if two objects are not equal to their equals(Object O) methods, then the hashCode values are not required to be equal, but in this case try to ensure that the Hashcodes are different to improve performance.

At the same time, there is a description in the annotation section:

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.

As we know from the above description, hashCode is normally mapped from the memory address of the object. This is where the hashCode is generated based on the address of the object.

However, we know that the memory address of the object changes when the JVM performs GC, whether it is a tag copy algorithm or a tag collation algorithm. But HashCode requires it to remain the same. How exactly does the JVM do this? Another question is, if an object is moved to another location and its original location is filled by another object, will the newly populated object be the same as the previous object hashCode?

Let’s explore the implementation of the JVM.

From the above examples, it is clear that the original HashCode value is stored somewhere for reuse during GC operations. In the case of Hotspot, the most straightforward way to do this is to partition a portion of the object’s header area (25 bits on 32-bit machines, 31 on 64-bit machines) to store the hashCode value. But this adds extra information to the object, and in most cases the hashCode method is not called, resulting in a waste of space.

So how is the JVM optimized? When the hashCode method is not called, the location in the object header used to store hashCode is 0, and the corresponding hashCode value is computed only when the hashCode method (essentially System#identityHashCode) is called for the first time, And store it in the Object header. When called again, it simply gets the calculated HashCode.

The above implementation ensures that the value of HashCode will not be affected even if GC occurs and the object address changes. For example, if the hashCode method is called before GC occurs, the hashCode value is already stored, even if the address changes; This is especially true when calling the hashCode method after GC occurs.

We’ve mentioned the hashCode method several times above, as well as the identityHashCode method, which is identical to the identityHashCode method provided in the System class if you just look at the hashCode method of the Object class. In practice, however, we often override the hashCode method, and the hashCode value stored in the Object header can be one of the parent Object class and one of the implementation class.

In the OpenJDK, the header stores the hashcode obtained by System#identityHashCode, while the hashcode of a subclass of the overridden hashcode method is obtained by calling its implementation method in real time.

So, if a class’s hashCode method is overridden, can you still get the original hashCode? The System#identityHashCode method can return an immutable hascode value, regardless of whether the current object overrides the hashCode method.

To verify this, create a Person class that implements the hashCode method:

public class Person { private int id; @override public int hashCode() {return objects.hash (id); }}Copy the code

The verification code is as follows:

Person person = new Person();
person.setId(1);

System.out.println("Hashcode = " + person.hashCode());
System.out.println("Identity Hashcode = " + System.identityHashCode(person));
Copy the code

Execute the verification program and print the following result:

Hashcode = 32
Identity Hashcode = 1259475182
Copy the code

You’ll notice that the System#identityHashCode method uses the default hashCode method, not the hashCode method overridden by the Person object. Essentially the Object hashCode method is also the called identityHashCode method.

Hashcode = hashCode = hashcode = hashcode = hashcode We still use the JOL dependency library to write a program that looks at how the Object header information changes after the hashCode method is called.

Object person = new Object(); System.out.println(ClassLayout.parseInstance(person).toPrintable()); // Call the hashCode method, or System#identityHashCode method system.out.println (person.hashcode ()) if the hashCode method is overridden; // System.out.println(System.identityHashCode(person)); / / print the information in the object the JVM again System. Out. The println (ClassLayout. ParseInstance (person). ToPrintable ());Copy the code

After executing the above procedure, the console prints the following:

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 totalCopy the code

Before and after calling the hashCode method, we can see that the Value of the row with OFFSET 0 is changed from 1 to 613163265, which means that the hashCode Value is stored. If the corresponding method is not called, no storage takes place.