Java对象堆内存布局由对象头、实例数据和对齐填充组成，可通过JOL工具静态分析并验证；JOL输出偏移、大小、类型等详细信息，区分Shallow Size与实际占用，且受JVM参数如CompressedOops影响。

Java 对象在堆中的内存布局不能直接通过 Java 代码“看”到，但可以通过工具和方法还原出它在 HotSpot JVM 堆里的真实结构：对象头（Header）、实例数据（Instance Data）、对齐填充（Padding）。关键不是“运行时查看”，而是“静态分析 + 工具验证”。

用 JOL 打印对象的完整内存分布

JOL（Java Object Layout）是 Oracle 官方推荐的轻量级工具，无需运行时代理，调试时插入一行代码就能输出对象在堆中每个字节的归属。

• 添加 Maven 依赖：<dependency><groupId>org.openjdk.jol</groupId><artifactId>jol-core</artifactId><version>0.17</version></dependency>
• 在 debug 断点处执行：System.out.println(ClassLayout.parseInstance(obj).toPrintable());
• 输出含 OFFSET（偏移）、SIZE（字段占字节）、TYPE（类型）、VALUE（值）、INSTANCE SIZE（总大小）等列，例如空 Object 显示为 16 字节：Mark Word 占 8 字节、Klass Pointer 占 4 字节（开启 CompressedOops）、4 字节对齐填充

区分 Shallow Size 和实际堆占用

JOL 的 totalSize() 返回的是浅层大小（Shallow Size），即对象自身在堆中占的字节数，不含它引用的其他对象。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• GraphLayout.parseInstance(obj).totalSize()：返回该对象及其所有字段直接占用的总字节数（含对齐填充）
• 注意：String 的 value 字段只算一个引用（4 或 8 字节），其内部 char[] 占用不计入该 String 的 Shallow Size
• 数组对象如 new int[10]：头 24 字节（64 位 JVM）+ 10×4 = 64 字节（含可能的填充）

确认 JVM 参数对布局的影响

对象大小不是固定的，取决于 JVM 启动参数，尤其是是否启用压缩指针（CompressedOops）和是否开启指针对齐。

立即学习“Java免费学习笔记（深入）”；

• 调用 VM.current().details() 可打印当前 JVM 配置，包括：UseCompressedOops=true、ObjectAlignmentInBytes=8 等
• 关闭 CompressedOops（如加 -XX:-UseCompressedOops）后，Klass Pointer 从 4 字节变为 8 字节，空 Object 会变成 24 字节（8+8+8）
• 对象头中 Mark Word 大小也随锁状态动态变化，但存储空间固定（64 位 JVM 总是 8 字节）

配合 jmap 查看堆中对象分布情况

JOL 给的是单个对象的理论布局，jmap 则反映真实堆中大量对象的统计分布，两者互补。

• jmap -histo <pid>：列出当前堆中各类对象实例数、总字节数、平均大小（粗粒度）
• jmap -heap <pid>：显示堆总体布局（新生代/老年代比例、GC 算法等），辅助判断对象生命周期与内存压力
• 若发现某类对象数量突增或平均大小异常（比如比 JOL 预期大很多），说明可能存在字段冗余、未及时清理引用或序列化膨胀等问题