Java中Object.hashCode()默认实现不直接返回内存地址，而是首次调用时基于对象内存地址（或线程相关随机数）生成并缓存在对象头中的32位不可变整数，后续调用直接返回该值。
Java 中 Object.hashCode() 的默认实现并不直接反映对象在内存堆中的地址，但它在绝大多数 JVM 实现（如 HotSpot）中，**初始值确实由对象的内存地址经哈希运算生成**，因此可作为理解对象“内存唯一性”的一个实用切入点——不过需注意：它不是地址本身，也不保证全程不变。
默认 hashCode 的底层机制（以 HotSpot 为例）
HotSpot JVM 中，未被重写的 hashCode() 调用的是 Object.hashCode() 的本地实现，其行为如下：
- 首次调用时，JVM 会基于对象分配时的内存地址（或与其强相关的随机数/线程局部状态）计算一个 32 位整数，并将其存储在对象头（Mark Word）的特定字段中；
- 该值一旦生成即被缓存，后续调用直接返回，**不随 GC 移动而更新**（即对象被移动后，hashCode 保持原值）；
- 这意味着它本质上是一个“创建时绑定的、不可变的标识快照”，而非实时内存地址指针。
为什么不能把 hashCode 当作真实地址？
尽管有地址渊源，但以下原因决定了它不能等同于内存地址：
-
地址不可直接获取：Java 不暴露原始指针，
System.identityHashCode()才是获取默认哈希值的规范方式（即使对象重写了hashCode()，它仍能返回默认值）； - 可能被折叠或冲突：32 位整数空间远小于 64 位地址空间，多个不同地址可能映射到同一 hash 值（哈希碰撞）；
-
启动参数可改变行为：通过
-XX:hashCode=N可切换算法（如 N=0 表示随机数，N=1 表示内存地址相关，N=5 表示全局递增序列），说明其非固定语义。
如何验证对象的“默认哈希唯一性”与内存位置的关系？
可通过对比 System.identityHashCode() 和对象是否相等来观察规律：
立即学习“Java免费学习笔记（深入）”；
- 两个
new Object()实例，只要未重写hashCode()，它们的identityHashCode极大概率不同（尤其在小规模创建时）； - 对同一对象多次调用，结果恒定，哪怕发生 Young GC 或对象晋升到老年代；
- 若使用
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（需 hsdis）可深入查看 JIT 编译后的 native 实现，但日常开发无需至此。
实际开发中应如何正确看待这个值？
它是一个轻量级的、用于散列表快速分桶的“身份代理”，设计目标是高效与一致性，而非内存可视化：
- 在
HashMap、HashSet等集合中，它是定位桶的关键依据（配合equals()）； - 调试时可用
System.identityHashCode(obj)快速区分两个看似相同的对象实例（比如日志中打印@后的十六进制值，本质就是 identityHashCode 的无符号十六进制表示）； - 切勿在持久化、网络传输或跨 JVM 场景中依赖它——它不具备跨进程/重启稳定性。
不复杂但容易忽略：默认 hashCode 是 JVM 对“对象身份”做的一个工程折中——既利用了内存分配的局部性，又规避了暴露地址带来的安全与移植风险。理解它，关键在于把握“初始化绑定、不可变、非地址、服务于哈希表”这四个要点。
