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

System.identityHashCode()：获取对象原始内存哈希值的“直通车”

在Ja va的世界里，对象的身份和它的“内容”有时是两码事。当你需要穿透类重写的hashCode()方法，直接触及对象在JVM中的原始身份标识时，System.identityHashCode()就是那把精准的钥匙。它的核心使命非常明确：返回对象在JVM中的“身份哈希码”，这个码与对象的内存地址或内部唯一ID强相关，完全独立于任何类级别的hashCode()重写逻辑。这意味着，无论对象的类如何定义其哈希值，调用这个方法总能获得其最原始的身份标识。

为什么它能免疫重写的影响？

关键在于两者的“出身”不同。identityHashCode是JVM层面为每个对象打上的“出厂编号”。这个编号在对象创建时便已确定，并固化在对象头（例如mark word）中。而当我们调用obj.hashCode()时，实际上是在触发一个动态方法调用——JVM会去寻找并执行该对象所属类定义的hashCode()实例方法。如果类重写了它，就执行重写后的业务逻辑；如果没重写，才会回退到默认的Object.hashCode()实现，而这个默认实现的底层，恰恰就等同于调用了System.identityHashCode(this)。所以说，identityHashCode是源头，而重写的hashCode()只是下游可能被修改的“出口”。

如何正确使用它？

使用起来相当直接，但有几个细节需要留意：

• 直接调用：传入任意对象引用即可，例如System.identityHashCode(str)或System.identityHashCode(list)。
• 无视重写：即使对象来自String、ArrayList或任何自定义的、重写了hashCode()的类，返回的值始终反映其“身份”，而非业务语义上的哈希值。
• 注意空值：对null调用会返回0，使用时做好判空是良好习惯。
• 保证稳定性：同一对象在其生命周期内，多次调用此方法返回值必定相同。即便发生GC导致对象内存位置移动（在使用了压缩指针等策略的JVM中），JVM也会确保其identityHashCode的唯一性和稳定性。

与普通hashCode()的典型对比

来看一个具体的例子就一目了然了：

class Person {
    String name;
    public Person(String name) { this.name = name; }
    @Override public int hashCode() { return name != null ? name.hashCode() : 0; }
}

对于这个类：

• new Person(“Alice”).hashCode() → 返回的是字符串“Alice”的内容哈希值，这是由重写逻辑决定的。
• System.identityHashCode(new Person(“Alice”)) → 返回的是这个新建对象实例的原始身份哈希，每次new都会得到一个不同的值，与“Alice”这个名字无关。
• 因此，两个new Person(“Alice”)实例，用hashCode()比较是相同的（因为名字相同），但用identityHashCode()比较则一定不同，因为它们根本就是两个不同的对象。

适用场景与注意事项

那么，什么时候该请出这位“身份鉴定官”呢？它主要适用于以下场景：

• 调试与诊断：快速区分“内容相同但非同一对象”的情况，比如在深拷贝前后验证对象是否真的是两个独立实例。
• 特殊数据结构：实现像IdentityHashMap这样基于对象身份（而非内容相等性）的映射或缓存。
• 排查集合异常：当遇到哈希冲突或集合去重行为不符合预期时，用它来验证你操作的是否为同一个对象实体。

最后需要提醒的是，它的用武之地在于“身份识别”，而非“逻辑相等性判断”。如果需要基于对象的业务内容来判断是否相等，那还是应该依赖equals()与hashCode()这对经典组合。System.identityHashCode()更像是一个系统级的调试工具和特定场景的构建基石，理解其原理，才能在合适的时机精准运用。