Why did the location of the object change in the JVM?

Question

This is what I tried:

public final class firstObj{ public static void main(String args[]){ Object obj = new Object(); Object obj1 = new Object(); System.out.println(obj); System.out.println(obj1); } } 

First, I compiled the program and ran it two times in a row, I got two different outputs:

output 1:

 java.lang.Object@6f548414 java.lang.Object@65ab7626 

output 2:

 java.lang.Object@659c2931 java.lang.Object@6f548414 

I want to know why the JVM replaced the second location of the object with the first location of the object. When it started a second time .. it is quite confusing ..,

Answer 1

hashCode () has little to do with memory locations. Although this may look like an address, it is just a randomly generated number.

I did not expect it to always stand out from the same segment, but I needed to know if the objects were selected one at a time, since my result showed a bit of such a pattern

It can be expected that this is a random number.

---

If you run this in OpenJDK or Oracle access point, you will get.

 import sun.misc.Unsafe; import java.lang.reflect.Field; public class ObjectAddress { public static void main(String[] args) { Object o1 = new Object(); Object o2 = new Object(); Object o3 = new Object(); Object[] os = {o1, o2, o3}; System.out.println("Before using hashCode"); for (int i = 0; i < os.length; i++) { int address = UNSAFE.getInt(os, UNSAFE.arrayBaseOffset(Object[].class) + i * 4); int hashCode = UNSAFE.getInt(os[i], 1L); System.out.println(i + ": " + Integer.toHexString(address) + " hashCode " + Integer.toHexString(hashCode)); os[i].hashCode(); } System.out.println("After using hashCode"); for (int i = 0; i < os.length; i++) { int address = UNSAFE.getInt(os, UNSAFE.arrayBaseOffset(Object[].class) + i * 4); int hashCode = UNSAFE.getInt(os[i], 1L); System.out.println(i + ": " + Integer.toHexString(address) + " hashCode " + Integer.toHexString(hashCode) + " for " + os[i]); UNSAFE.putInt(os[i], 1L, 0x12345678); } System.out.println("After setting the hashCode"); for (int i = 0; i < os.length; i++) { int address = UNSAFE.getInt(os, UNSAFE.arrayBaseOffset(Object[].class) + i * 4); int hashCode = UNSAFE.getInt(os[i], 1L); System.out.println(i + ": " + Integer.toHexString(address) + " hashCode " + Integer.toHexString(hashCode) + " for " + os[i]); os[i].hashCode(); } } static final Unsafe UNSAFE; static { try { Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe"); theUnsafe.setAccessible(true); UNSAFE = (Unsafe) theUnsafe.get(null); } catch (Exception e) { throw new AssertionError(e); } } } 

you will get something like

 Before using hashCode 0: d8e78160 hashCode 0 1: d8e78170 hashCode 0 2: d8e78180 hashCode 0 After using hashCode 0: d8e78160 hashCode 68111f9b for java.lang.Object@68111f9b 1: d8e78170 hashCode 3c322e7d for java.lang.Object@3c322e7d 2: d8e78180 hashCode 3e2f1b1a for java.lang.Object@3e2f1b1a After setting the hashCode 0: d8e78160 hashCode 12345678 for java.lang.Object@12345678 1: d8e78170 hashCode 12345678 for java.lang.Object@12345678 2: d8e78180 hashCode 12345678 for java.lang.Object@12345678 

You can see that each object has 16 bytes.

Answer 2

Unlike C, where a request for a new object returns a pointer that will be presented with the same unique bit pattern throughout its life cycle, most Java implementations store links using bit patterns that can change as the program starts (link the object can store the physical location of the object in memory, if the GC wants to move the object, it pauses all threads, updates every link to this object that exists anywhere in the universe to indicate a new m location, then continue to flow). Having an immutable basically unique 32-bit number available for describing each object is almost as useful as having an immutable 32-bit value that will be completely unique for each live object, or a 64-bit value that can be unique for each of an object ever created, but cheaper and easier to implement (saving a 64-bit value would increase by 8 bytes of storage required for each object, but it would be advantageous to establish a constant rating among all objects, which would be This is useful in some situations, such as collecting or caching with multiple locks, although it is sometimes useful to set a constant rating for objects, allowing classes that need this ranking to be better than using the system [although it may be useful to have a system method that if a call from several threads will return a guaranteed unique 64-bit number, which will strictly increase on each thread and will generally correspond approximately to the age of the object, but whic h will avoid the cost of Growth AtomicLong ]

Hexadecimal numbers included in the string representations of objects by default have no meaning, except that any given object will always indicate the same number, and individual objects usually report different numbers. I don’t know if there is any special reason why numbers appear randomly and are not counted from scratch and then wrap around, but I would suggest that Java developers would like to deny people that they are doing something that will rely on a hash of value objects that have anything to do with each other.