如何通过 Object.hashCode() 的默认实现理解其在 64 位 JVM 中为何并不是对象的物理地址？
Object.hashCode()默认实现并非物理地址，而是由HotSpot虚拟机采用惰性生成的identityhashcode，基于全局计数器或线程随机数确保唯一性，首次调用时生成并存入对象头markword，该值固定不变且不随GC移动而变化，用于对象身份标识。
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 上都会悄无声息地崩掉——别踩这个坑。