如何通过 Object.hashCode() 的默认实现理解其在 64 位 JVM 中为何并不是对象的物理地址？

Object.hashCode() 默认实现与对象内存地址无关：HotSpot中采用惰性生成的identity hash code，基于全局计数器或线程随机数，固定后存于对象头，不随GC移动而变化。

Object.hashCode() 默认实现和对象地址无关

先来个直白的结论：Ja va 的 Object.hashCode() 默认实现（也就是没被重写时），在 HotSpot JVM 里压根不返回对象的内存地址，哪怕你现在跑在 64 位 JVM 上也一样。很多人从“哈希码应该能唯一标识对象”这个直觉出发，容易产生误解——但 JVM 的合同说得明明白白：hashCode() 只需要满足“相等对象必须有相同哈希码”这一条，至于能不能逆推地址、会不会冲突、跟地址绑不绑定，它一概不管。

HotSpot 中默认 hashCode 的生成逻辑

HotSpot 用的是一套叫“identity hash code”的机制。这个值在对象第一次调用 hashCode() 时才懒洋洋地生成，然后直接塞到对象头（mark word）里存着。具体怎么生成？取决于 JVM 启动参数和当前运行时状态：

• 默认情况（-XX:+UseBiasedLocking 开启时）：用一个全局原子计数器算出来——计数器初始为0，首次调用时取当前值并自增，简单粗暴。
• 要是关了偏向锁（-XX:-UseBiasedLocking）或者在某些 GC 场景下：可能改走线程局部随机数（os::random()）的路子，再经过一点简单扰动。
• 关键：这个值一旦生成就焊死了，后面再调用直接返回缓存值。不管你对象被 G1 还是 CMS 搬到哪里，跟它没半毛钱关系。

换句话说：同一个对象，在不同 JVM 实例里、甚至同一 JVM 不同次运行时，hashCode() 的值都可能不一样；而真实的物理地址（比如你用 Unsafe.getAddress() 抓到的）每次新建对象都会变，GC 一跑更是必然变。二者根本不在一个频道上。

为什么不能把 hashCode 当作地址用？

要是硬把 hashCode() 当地址使，后果会很严重：

• 地址空间错位：64 位地址整整 64bit，而 hashCode() 只有 int（32bit 有符号），高位信息直接丢掉，相当于拿半张地图找路。
• GC 不安全：ZGC、Shenandoah 这类支持并发搬移的 GC 会随时移动对象，但 hashCode() 的值纹丝不动——你要是拿它当地址去读内存，要么读到旧位置（很可能已经被释放或覆写），要么直接越界。
• 调试误导：用 jmap -histo 或者 JOL（Ja va Object Layout）看对象布局时，显示的“address”是 GC 视角的起始地址（比如 0x0000000800010000），而 System.identityHashCode(obj) 返回的可能是 182374912，二者数值上毫无映射关系。

真想拿到对象运行时的真实地址，得凑合用 Unsafe 加 objectFieldOffset 配合 getLong() 来折腾——但这套操作是非标准的、不可移植的，而且只建议在调试时碰一碰，十分危险。

验证方式：用 JOL 和 System.identityHashCode 对比

最直观的方法就是亲自测一遍：

import org.openjdk.jol.vm.VM;
import org.openjdk.jol.info.ClassLayout;
import ja va.util.*;

public class HashCodeVsAddress {
    public static void main(String[] args) {
        Object a = new Object();
        Object b = new Object();
        System.out.println("a identityHashCode: " + System.identityHashCode(a));
        System.out.println("b identityHashCode: " + System.identityHashCode(b));
        System.out.println("VM address bits: " + VM.current().addressSize());
        System.out.println("JOL layout:\n" + ClassLayout.parseInstance(a).toPrintable());
    }
}

输出里你会看到：identityHashCode 是两个接近但不连续的整数（比如 123456789 和 123456790），而 JOL 显示的地址类似 0x0000000800012340 —— 两者既不线性相关，也不模 2³² 同余。这种差异不是偶然的，是 HotSpot 主动设计出来的结果。

最后提醒一句：任何依赖 hashCode() 来表示位置、做指针运算、或者跨进程传递的逻辑，在 64 位 JVM 上都会悄无声息地崩掉——别踩这个坑。