对付类与对象内存布局的深度追问，靠的不是背更多结论，而是把已知结论连成网络：一个对象在堆里到底占多少、为什么这么占、和继承有什么关系。追问本质是顺着这张网走的，网密的人不怕问。这道题的分水岭，在于能不能从"对象有多大"推到"字段怎么排、对齐怎么补、引用指向哪"。
先把结论立住：一个对象在堆里由三部分组成
一句话：Java 对象在堆上的内存布局通常分三块——对象头、实例数据、对齐填充。对象头又含标记字（mark word）和类型指针（klass pointer）；实例数据按字段类型依次排列，父类字段排在子类字段之前；对齐填充把总大小补齐到 8 字节的整数倍。
这里要先立住一个前提：引用和对象是两个东西。局部变量表或成员变量里存的是"引用"（在栈上或对象内部，开启压缩指针时占 4 字节），真正对象在堆上。很多人把"引用的大小"和"对象的大小"混为一谈，于是算内存时少算一截，或被"为什么两个对象 equals 却地址不同"这类问题绊倒。
机制拆解：对象头、字段排列与对齐
对象头的第一部分是标记字，存哈希码、锁状态、GC 分代年龄等运行时信息，在 64 位机上通常占 8 字节。第二部分是类型指针，指向方法区的类元数据（类结构、虚方法表等），开启压缩指针（-XX:+UseCompressedOops，服务端默认开）时占 4 字节，否则 8 字节。
实例数据部分按字段的声明顺序和继承层级排列：先父类字段、后子类字段；同层里基本类型按自身大小排（long/double 8 字节，int/float 4，short/char 2，byte/boolean 1），引用占 4（压缩）或 8 字节。对齐填充不是"额外塞数据"，而是 JVM 要求对象起始地址和大小满足 8 字节对齐，不足时在末尾补 0——这也是为什么一个只有两个 int 字段的对象，算下来往往不是 8+8 那么简单，而是被对齐撑到下一个 8 的倍数。
数组对象比普通对象多一个"长度"字段（4 字节），因为数组类型在运行期才知道长度，无法靠类元数据描述。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 类与对象内存布局：头 + 实例数据 + 对齐填充
class Base {
int a; // 4 字节，父类字段排在前面
}
class Sub extends Base {
boolean f; // 1 字节
long b; // 8 字节，按 8 对齐，前面可能留 3 字节填充
int c; // 4 字节
Object ref; // 引用 4 字节（压缩指针开启时）
}
// 引用在栈（局部变量），对象在堆
Sub s = new Sub(); // s 是引用(4字节)，new Sub() 的实例在堆上
Base up = s; // 向上转型，引用类型变 Base，指向的还是同一个堆对象
// 数组对象额外带长度字段
int[] arr = new int[100]; // 对象头 + 长度(4) + 100*4 的 int 区
这段代码值得盯三处：第一处，Base a 作为父类字段排在 Sub 自身字段之前，这是"继承链上字段排列顺序"的落点；第二处，long b 要求 8 字节对齐，它前面的 boolean f 之后可能插入填充，理解这点才能正确估算对象大小；第三处，up = s 只是引用类型变了，堆上那个对象的大小和布局一点没变——印证"引用和对象是两回事"。
最常见的几个坑
最常见的坑是估算对象大小时漏算对象头与对齐填充。一个只有一两个字段的小对象，光对象头就占了 12~16 字节，对齐后实际占用往往是 8 的倍数而非"字段之和"。在缓存设计、对象池、序列化体积评估时，这种低估会直接导致容量规划偏差。
其次是把引用大小当成对象大小，或反过来。一个 Map<String, Object> 存一万个对象，算内存不能只算 key/value 引用，还要把每个 value 指向的堆对象本体算进去；同样，算对象内部字段也不能漏掉它持有的引用所指向的下游对象。
还有一个更隐蔽的坑：以为字段顺序不影响内存。字段排列受继承层级和类型大小影响，不当的顺序会制造大量填充空洞（比如把多个 1 字节 boolean 散落在 long 之间）。把同尺寸字段聚拢、按"大字段在前"排，能减少填充、压缩对象体积——在百万级对象场景下，省下的内存相当可观。
再一个是忽略压缩指针开关对布局的影响。开启 -XX:+UseCompressedOops 时引用与类型指针都是 4 字节，关掉则变 8 字节，同一份代码在两种配置下对象大小不同。做内存画像时先确认这个开关，否则结论会差出一截。
面试中的经典追问
"请简单介绍一下对象的内存布局？"——一句话定位：对象头 + 实例数据 + 对齐填充，头里含标记字和类型指针；一个场景佐证：算对象大小、做缓存容量规划时离不开它；一个边界收尾：引用和对象是两回事，引用大小不等于对象大小。按"结论—依据—边界"三步走最稳。
"对象头里都存了什么？"——动机是"运行时需要在对象上挂元数据"，机制是标记字存哈希/锁/GC 年龄、类型指针指向类元数据，代价是对象再小也要背上这十几字节；讲到这再补"压缩指针能让类型指针从 8 缩到 4"，基本就稳了。换个角度：如果让你给一批对象做内存画像，你会量哪些指标？
"继承对内存布局有什么影响？"——先列层级关系：父类字段排在子类之前、每层各自对齐；再按"字段顺序影响填充"给场景结论。选型时把"继承层级过深会放大填充与耦合"摆到台面上，再决定要不要拆。
"你在项目里因为内存布局踩过什么坑？"——行为题，拿真实案例说话。比如曾用对象存海量小结构，因对齐填充导致实际内存远超预估、触发频繁 GC，后用更紧凑的字段排列或基本类型数组替代才压下来。讲"复现—定位—修复"的结构，比空谈概念有说服力得多。
工程落地：真实项目里怎么用
内存布局在项目里的高频落点：一是缓存与对象池的容量规划，按"头 + 字段 + 对齐"估算真实占用，而不是凭字段数拍脑袋；二是大量小对象场景（如解析后的结构体）用基本类型数组或更紧凑的编码替代对象，减少对象头与填充带来的 overhead；三是热对象尽量缩小体积，让它在年轻代就被回收，减少晋升到老年代的压力；四是排查内存泄漏时，沿"引用 → 对象 → 下游引用"逐层看，而不是只看引用计数。
一个稳妥的工程约定：高频创建的对象保持字段紧凑（同尺寸聚拢、大字段在前）；做容量评估先确认压缩指针开关；缓存键优先用基本类型或短字符串；对象体积纳入 code review 的关注项。把这几条固化，内存相关的性能与 OOM 坑能少一大半。
还有一处和内存布局紧密相关的优化值得提：逃逸分析能让"只在方法内局部使用、没有逃出方法作用域"的对象直接在栈上分配甚至消除分配，从而减少年轻代压力。这解释了为什么某些短生命周期的小对象并不会真的拖垮 GC——JIT 在确认它们不逃逸后，会做标量替换，把它们拆成基本类型直接在栈帧上排布。所以评估对象开销时，既要算"对象本身多大"，也要看它"有没有逃逸、能不能被优化掉"，两者一起看才接近真实代价。
数组的连续内存还带一个实战含义：遍历数组比遍历链表对 CPU 缓存更友好，因为相邻元素落在同一缓存行，硬件预取器能提前把数据搬进缓存；反之 LinkedList 的节点散落在堆各处，遍历时 cache miss 偏高。这也是为什么在热点路径上用 int[] 而非 LinkedList<Integer>，往往能换来可观的提速——内存布局的影响会一路传导到运行性能。
给正在准备面试的你
理解内存布局之后，需要在真实项目里练一遍：用 java.lang.instrument.Instrumentation 或 jol 工具打印一个你写的小对象的实际布局，对照"头 + 字段 + 对齐"算一遍；再故意把字段顺序打乱，看大小怎么变。这两步做下来，比再读三遍资料都管用。
如果只记两句话，就记这两句：第一，一个对象 = 对象头（标记字 + 类型指针）+ 实例数据（父类字段在前）+ 对齐填充（补到 8 的倍数）；第二，引用和对象是两回事，估算内存要把对象本体和下游引用都算上。把这两句讲顺，内存布局这一关就过了。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android 软件开发面试·从入门到精通」连载系列
上一篇：面向对象三大特性：封装、继承、多态怎么讲才透
下一篇预告：构造方法与初始化顺序：父类子类谁先执行
有任何问题欢迎在评论区留言交流。
