如何在 Java 中利用 System.identityHashCode() 获取对象的物理内存哈希值标识-java教程-PHP中文网

system.identityhashcode() 返回jvm分配的唯一稳定标识而非真实内存地址，因jvm规范未强制要求、gc移动对象需保持原值、指针压缩导致地址不可直接映射。

如何在 java 中利用 system.identityhashcode() 获取对象的物理内存哈希值标识

System.identityHashCode() 并不返回对象的“物理内存地址”，而是返回 JVM 为该对象分配的一个**唯一、稳定、与 equals/hashCode 无关的整数标识**，其底层通常基于对象首次被访问时的内存地址（或其变换值），但不能等同于真实内存地址，也不保证跨 JVM 或跨运行时一致。

为什么 identityHashCode 不等于内存地址？

JVM 规范未强制要求 identityHashCode 必须是内存地址。实际实现中（如 HotSpot）： - 对于未被 GC 移动的对象，它常由对象头中存储的“mark word”部分生成，可能包含压缩后的地址信息； - 对于经过 GC（如 G1、ZGC）移动过的对象，JVM 会保留原始 identityHashCode 值，而非更新为新地址； - 启用指针压缩（-XX:+UseCompressedOops）时，地址本身已被压缩，更无法直接映射为 32 位 int。

如何正确使用 identityHashCode？

它的核心用途是：在需要区分“同一性（==）”而非“相等性（equals）”的场景下提供轻量级标识：

实现自定义哈希容器时，避免用户重写 hashCode() 导致的冲突（如 WeakHashMap 内部就依赖它）；
调试时快速判断两个引用是否指向同一对象实例（尤其在 equals 被重写后）；
日志中打印对象唯一标识，避免 toString() 被重写导致混淆；
实现对象生命周期监控、内存泄漏初步排查（配合 jmap/jstack 观察相同 identityHashCode 是否长期存在）。

常见误区与注意事项

以下做法不可靠或错误：

Gradle 9.8.0

下载

不要用它还原内存地址：无法通过 identityHashCode 反推出 Object 的真实内存位置（无公开 API，且受 GC、压缩指针等影响）；
不要用于跨 JVM 比较：不同 JVM 实例中同一类的相同对象，identityHashCode 值完全无关；
不要假设它单调递增或连续：分配顺序、GC 行为、线程竞争都会影响其值分布；
慎用于持久化或网络传输：它只在当前 JVM 生命周期内有效，序列化后失效。

简单验证示例

可辅助理解其行为：

Object a = new Object();
Object b = new Object();
Object c = a; // 引用相同
<p>System.out.println(System.identityHashCode(a)); // 如：123456789
System.out.println(System.identityHashCode(b)); // 如：987654321（通常不同）
System.out.println(System.identityHashCode(c)); // 同 a，如：123456789
System.out.println(a == c); // true
System.out.println(a.equals(c)); // true（Object 默认实现即 ==）</p>

注意：即使 a 和 b 是同一类的两个新实例，它们的 identityHashCode 几乎总是不同；但若发生极端哈希冲突（极罕见），JVM 会通过内部机制确保其仍能区分对象同一性。