Java不暴露真实内存地址，因JVM抽象层和GC移动性使地址无稳定语义；IDEA调试器不显示指针是规范限制而非功能缺失，应使用Calculate Retained Size等工具分析内存占用与引用关系。
Java 本身不暴露真实内存地址，System.identityHashCode() 返回的也不是地址，而是基于对象初始内存位置计算出的一个哈希值——它可能被复用、重排、甚至在 GC 后失效。IDEA 的调试器也**不提供真实指针地址**，这是 JVM 规范决定的，不是 IDE 功能缺失。
为什么不能看到真实内存地址
Java 运行在 JVM 抽象层之上，对象地址由 GC 管理，随时可能移动（如 G1 或 ZGC 的压缩阶段）。所谓“地址”在 Java 层面没有稳定语义，IDEA 不会、也不能显示一个随时会变、且对用户无实际用途的十六进制指针。
-
System.identityHashCode(obj)只是对象标识的近似，同一对象多次调用可能不同（尤其启用了-XX:+UseCompressedOops或发生 GC 后） - 使用 JNI 或 JOL（
Unsafe）能拿到地址，但那已脱离调试器范畴，且需额外权限和工具链 - IDEA 的 Variables 面板里显示的
@xxxxxxx（如@1f32e575）是toString()默认实现的哈希后缀，不是地址，也不保证唯一
用 Calculate Retained Size 替代“看地址”的真实意图
多数人想查“地址”，其实是想知道：“这个对象到底占了多少内存？它是不是被别的东西强引用着？有没有泄露？”——这些需求，Calculate Retained Size 比地址更有用。
- 右键 Variables 面板中的对象 → 选择
Calculate Retained Size，IDEA 会触发一次轻量级堆分析，返回该对象及其所有可达子对象的总大小（单位：字节） - 结果中若显示
0 B，说明该对象已被标记为待回收（但尚未执行），或已不可达 - 注意：此操作会暂停 JVM 并扫描堆，大数据量对象（如大
ArrayList）可能卡顿几秒，别误以为卡死
需要真正地址时的替代路径
如果你确有底层调试需求（比如验证对象布局、对齐、字段偏移），必须跳出 IDEA 调试器，改用专用工具：
- 用
jol（Java Object Layout）：在代码中加ClassLayout.parseInstance(obj).toPrintable()，输出包含字段偏移、填充、对象头等精确信息 - 生成堆转储（
jmap -dump:live,format=b,file=heap.hprof <pid></pid>），用 IDEA 打开后，在Instances视图中可看到每个对象的Address列（这是 dump 时刻的逻辑地址，非运行时指针） - VisualVM / JProfiler 连接运行中进程，Heap Walker 中部分视图会显示类似
0x0000000800a1b2c0的地址，但仅作参考，不可用于计算或指针运算
真正要警惕的不是“看不到地址”，而是把 identityHashCode 当地址用、或在日志里靠 @ 后缀判断对象生命周期——这些做法在现代 JVM 上极易出错。观察引用关系、 retained size、GC 日志，比盯一个虚幻的地址靠谱得多。
