java中object.hashcode()不是对象内存地址，而是首次调用时基于线程随机数（openjdk 8起）或内存地址经哈希运算生成并缓存在对象头中的32位不可变整数，后续调用直接返回该值，不随gc移动更新。
不是，Java 中 Object 类的 hashCode() 返回值**不是对象的内存物理地址**，也不能直接用来获取或判断真实内存地址。它只是一个整型哈希码，设计初衷是支持哈希表（如 HashMap）高效工作，而非暴露底层内存布局。
为什么常被误解为“内存地址”？
早期文档和部分教材曾模糊描述为“通常基于内存地址计算”，加上 HotSpot JVM 在某些未初始化场景下确实用地址做初始输入，导致误传。但这是实现细节，且已被现代 JVM 明确放弃——OpenJDK 8 及以后版本默认使用线程局部随机数生成器（Marsaglia’s xorshift）计算 hashCode，与分配地址完全无关。
如何验证它不是内存地址？
可通过两个简单实验确认：
-
哈希冲突实验：创建百万个
new Object()实例，统计hashCode()重复次数。实测约 0.02% 冲突率（如 232 次重复），而真实内存地址不可能重复——说明输出空间远小于地址空间，本质是 32 位整数映射，非地址直接编码。 -
GC 后一致性实验：对一个对象调用
hashCode()，再触发一次 Full GC（可能将其移动到新内存区域），再次调用仍返回相同值。内存地址变了，哈希码不变——证明其值被固化存储在对象头中，与当前物理位置脱钩。
什么情况下看起来“像地址”？
仅在极少数未优化、未调用过 hashCode() 的新对象上，某些旧版 JVM（如 JDK 6 默认策略）可能用地址低位做快速哈希。但这属于：
• 临时启发式策略，不保证稳定；
• 不跨 JVM 版本、不跨 GC 算法、不跨启动参数（如 -XX:hashCode=0 强制禁用）；
• 一旦对象参与过哈希运算，该值即被缓存并锁定，后续地址变化不影响它。
真正可靠的内存地址查看方式
Java 标准 API **不提供获取对象物理地址的接口**，这是 JVM 抽象层有意屏蔽的。若需调试级观察（仅限开发/诊断）：
- 使用
Unsafe.objectFieldOffset()配合Unsafe.getLong()读取对象头（需反射解锁，且依赖 JVM 实现）； - 借助 JOL（Java Object Layout）工具配合
-XX:+PrintGCDetails或jcmd <pid> VM.native_memory</pid>辅助分析内存分布； - 注意：这些方法不稳定、不跨平台、不适用于生产环境，也不等同于 C 中的指针地址。
归根结底，把 hashCode() 当作内存地址既无依据，也违背 Java 设计哲学——它只承诺“同一对象多次调用结果一致”，不承诺可逆、不承诺唯一、更不承诺与地址相关。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
