Java中引用变量存储的是指向对象头的逻辑引用值，非真实内存地址；hashCode()和identityHashCode()均不表示物理地址，且受指针压缩、GC移动等影响不可预测。
Java里没有真正的内存地址，hashCode()不是地址
很多人看到 System.identityHashCode() 或对象打印出的 @1b6d3586 就以为这是JVM里的真实内存地址——其实不是。HotSpot JVM 从 Java 8 开始默认开启指针压缩（-XX:+UseCompressedOops），对象头里的“地址”字段存的是偏移量，不是物理地址；即使关掉压缩，identityHashCode 也只在对象未被锁、未被GC移动时才可能和地址沾边，且经过哈希扰动，完全不可预测。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 别用
System.identityHashCode()做唯一标识或调试地址用途，它不保证稳定，GC 后可能变 - 想看底层地址？得用
Unsafe+objectFieldOffset配合getLong，但仅限 debug 模式，生产禁用 -
toString()输出的@后十六进制是identityHashCode的无符号十六进制表示，不是地址，只是巧合长得像
引用变量到底存了什么：一个指向对象头的“句柄”
Java 引用变量（比如 String s = "abc"; 中的 s）在栈上存的，是一个逻辑上的“引用值”。这个值具体形式取决于 JVM 实现：HotSpot 用的是直接指针（direct pointer），即指向对象实例数据起始位置（也就是对象头）的地址；早期某些 JVM 用句柄池，引用存的是句柄地址。但无论哪种，你都**无法在 Java 层拿到或操作它**。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 不要试图用
==比较两个引用是否“指向同一块内存”，它比较的是引用值是否相等——这恰好能判断是否指向同一个对象，但原理不是地址比对，而是语义一致 - 如果需要观察引用行为，用
javap -v看字节码里的astore/aload，它们操作的就是这个抽象引用值，不是地址 - GC 移动对象时（如 G1 的 Evacuation），JVM 会自动更新所有引用变量里的值，你完全感知不到——正因如此，Java 才不需要程序员管地址
为什么 new String("a") == new String("a") 是 false？
因为 == 比较的是引用值是否相同，而两次 new 创建的是两个独立对象，即使内容一样，它们的引用值也不同。这跟 C/C++ 里两个 malloc 返回不同地址是一个道理——但关键区别在于：Java 不让你看到那个地址，只暴露“是否为同一对象”这一层语义。
常见错误现象：
- 误以为字符串字面量和
new String()创建的对象能用==判断内容相等 → 实际应使用.equals() - 在集合里用自定义对象当 key 却没重写
hashCode()和equals()→ 因为HashMap内部靠引用值定位桶，但查找时又依赖equals()，不一致就找不到 - 用
==判断 Integer 在 [-128, 127] 范围外是否相等 → 缓存失效，结果是 false，容易误判
真正该关心的不是地址，而是可达性与生命周期
JVM 管理内存的核心是 GC Roots 可达性分析，不是地址计算。一个对象是否存活，取决于从栈帧局部变量、静态字段、JNI 引用等 GC Roots 出发，能否找到一条引用链到达它。所谓“引用变量”，本质就是这条链上的一个节点。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 排查内存泄漏？用
jstack+jmap看对象引用链，而不是试图“算地址” - 想控制对象生命周期？用
WeakReference/PhantomReference，它们封装的是对引用可达性的干预能力，不是地址操作 - 序列化、RMI、JNI 场景下确实要接触“地址感”？那是在跨边界时由 JVM 底层映射处理，Java 代码层依然只能通过对象引用来交互
最常被忽略的一点：哪怕你用 Unsafe 获取到某个瞬间的地址，下一秒 GC 就可能把它挪走——所以任何基于“固定地址”的假设，在 Java 里都是脆弱的。
