System.identityHashCode() 返回JVM分配的唯一稳定标识而非真实内存地址，因JVM规范未强制要求、GC移动对象需保持原值、指针压缩导致地址不可直接映射。
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 是否长期存在）。
常见误区与注意事项
以下做法不可靠或错误：
- 不要用它还原内存地址：无法通过 identityHashCode 反推出 Object 的真实内存位置（无公开 API，且受 GC、压缩指针等影响）；
- 不要用于跨 JVM 比较：不同 JVM 实例中同一类的相同对象，identityHashCode 值完全无关；
- 不要假设它单调递增或连续：分配顺序、GC 行为、线程竞争都会影响其值分布；
- 慎用于持久化或网络传输：它只在当前 JVM 生命周期内有效，序列化后失效。
简单验证示例
可辅助理解其行为：
立即学习“Java免费学习笔记（深入）”；
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 会通过内部机制确保其仍能区分对象同一性。
