怎么通过 System.identityHashCode() 获取对象的原始哈希值而不受 hashCode 重写影响

有志者，事竟成！如果你在学习文章，那么本文《怎么通过 System.identityHashCode() 获取对象的原始哈希值而不受 hashCode 重写影响》，就很适合你！文章讲解的知识点主要包括，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

System.identityHashCode() 不返回内存地址，而是返回JVM为对象分配的稳定不变的标识哈希值；它不调用hashCode()、不受重写影响，在同一JVM中对同一对象始终唯一且不变。

System.identityHashCode() 真的返回对象内存地址吗

不是。它返回的是 JVM 为该对象分配的、与内存地址弱相关但**稳定不变**的标识哈希值，只要对象没被 GC，这个值就固定。它不调用 hashCode() 方法，也不受重写影响——这是它存在的根本原因。

注意：这个值在不同 JVM 实现或不同运行周期中可能不同，但**在同一 JVM 实例中，对同一对象始终唯一且不变**，哪怕对象字段变了、hashCode() 被重写了、甚至 equals() 返回 true，它都不变。

什么时候必须用 System.identityHashCode() 而不是 obj.hashCode()

当你需要区分「逻辑相等」和「物理同一」时。典型场景包括：

• 实现自定义缓存结构（比如基于对象引用而非内容做 key 的 WeakHashMap 内部逻辑）
• 调试时判断两个看似相同的对象是否真是同一个实例（尤其在集合去重、监听器重复注册排查中）
• 在重写了 hashCode() 的类上，想绕过业务逻辑直接看底层身份（例如验证某个工具类是否意外复用了对象）
• 序列化/反序列化后验证对象是否被重建（新对象 identityHashCode 必然不同）

常见误用和陷阱

最容易踩的坑是把它当“地址”来算偏移、传给 JNI 做指针操作——这完全错误。System.identityHashCode() 不是地址，不能解引用，也不能用于 Unsafe 操作。

另一个问题是混淆生命周期：对象被 GC 后，其 identityHashCode 可能被复用给新对象（JVM 实现相关），所以**绝不能跨 GC 周期持久化存储这个值做比较**。

示例对比：

String a = new String("hello");
String b = new String("hello");
System.out.println(a.equals(b)); // true
System.out.println(a.hashCode() == b.hashCode()); // true（String 重写了 hashCode）
System.out.println(System.identityHashCode(a) == System.identityHashCode(b)); // false（确实是两个对象）

替代方案？没有真正等价的纯 Java 替代

有人尝试用 Unsafe 读取对象头里的 hash 字段，但这依赖 HotSpot 内部结构、需反射获取 Unsafe 实例、且从 JDK 9+ 起权限收紧，实际不可靠也不推荐。

System.identityHashCode() 是 JVM 规范保证的、唯一标准且安全的途径。如果你发现它返回的值“看起来重复”，大概率是对象已被回收、新对象恰好分到同个 identity 值——这不是 bug，是设计使然。

真正要注意的，是别把它当成全局唯一 ID 用，也别在分布式或多 JVM 场景下依赖它。它只在单次 JVM 运行中，对存活对象有意义。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~