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 运行中，对存活对象有意义。
