Java对象在堆中由对象头、实例数据、对齐填充三部分组成；对象头含Mark Word和Class Pointer，实例数据为字段（含父类），对齐填充确保8字节对齐。
Java对象在堆内存中由哪几部分组成
Java对象在堆中不是一块连续裸数据，而是有明确分段结构的布局，HotSpot虚拟机（主流JDK默认）下分为三块：对象头、实例数据、对齐填充。其中对象头最复杂，又拆成 Mark Word 和 Class Pointer 两部分；实例数据就是你声明的字段（含父类字段）；对齐填充则纯粹为了保证对象起始地址是8字节倍数（即满足 java.lang.Object 的内存对齐要求）。
-
Mark Word存锁状态、GC分代年龄、哈希码（延迟计算）、线程ID（偏向锁时）等，同一内存位置复用不同含义 -
Class Pointer是指向Klass元数据的指针，32位JVM占4字节，64位默认也是4字节（开启-XX:+UseCompressedClassPointers） - 字段排列按“从大到小”重排序（如
long、double优先放前面），但同类型字段仍保持源码声明顺序 - 父类字段一定排在子类字段前面，哪怕子类字段类型更大
为什么 new Object() 占16字节而不是8字节
一个空 Object 实例：对象头占8字节（Mark Word 4字节 + 压缩类指针 4字节），实例数据为0字节，但必须补足到8字节对齐——所以加8字节 Padding，最终大小16字节。可通过 Unsafe.objectFieldOffset 或 JOL（Java Object Layout）工具验证：
new org.openjdk.jol.vm.VM().details()
输出显示 java.lang.Object 的 shallowSize 为16。
- 未开启压缩指针（
-XX:-UseCompressedOops）时，对象头变成12字节（Mark Word8 + 类指针 4？不对——64位下类指针也变8字节，实际对象头16字节），此时空对象会变成24字节 -
-XX:+UseCompressedOops必须搭配-XX:+UseCompressedClassPointers才能真正压缩两类指针；单独开前者不压缩类指针 - JDK 15+ 默认启用压缩指针，但堆大于32GB后自动失效，对象头膨胀，内存占用明显上升
如何查看某个对象的真实内存布局
别靠猜，用 JOL 工具最直接。添加 Maven 依赖后，在 main 方法里调用：
立即学习“Java免费学习笔记（深入）”；
System.out.println(VM.current().details());<br>System.out.println(ClassLayout.parseClass(MyClass.class).toPrintable());
输出包含字段偏移、类型、大小、是否被重排序等细节。注意：JOL 分析的是类模板布局，实际运行时还要考虑 GC 算法影响（比如 ZGC 的着色指针会让 Mark Word 额外承载元信息）。
- 字段偏移值不等于声明顺序索引，例如
int a; byte b; long c;中c可能偏移0，a偏移8，b偏移12 —— 因为 JVM 插入了填充避免byte拖累对齐 -
static字段和常量池内容不计入对象实例大小，它们在方法区（JDK 8+ 是元空间） - 数组对象额外多4字节长度字段，放在实例数据之前，紧跟对象头
对象布局对性能和并发的实际影响
布局不是纸上谈兵，它直接影响缓存行命中、锁升级路径、序列化体积甚至 Unsafe 操作安全性。
- 字段冷热分离很重要：把高频访问字段（如
AtomicInteger state）放在前面，可提升 L1 缓存局部性；把日志开关、调试标记等低频字段放后面，减少无效缓存加载 - 伪共享（False Sharing）就源于布局——两个 volatile 字段若落在同一缓存行（通常64字节），多核修改会反复使彼此缓存行失效；可用
@Contended注解（需-XX:+UnlockExperimentalVMOptions -XX:+RestrictContended）强制隔离 - 使用
Unsafe.objectFieldOffset获取字段地址时，拿到的是相对于对象起始地址的偏移，该值由布局决定，不同 JDK 版本或 VM 参数下可能变化，不可硬编码 - 序列化框架（如 Kryo）若依赖字段偏移做快速拷贝，就容易因布局变更出错；更安全的做法是走反射或生成字节码
对象布局细节藏得深，但只要涉及高性能、低延迟或底层操作，就绕不开它——尤其是当你发现 volatile 字段更新比预期慢，或者用 Unsafe 修改字段却没生效时，大概率是布局或指针压缩惹的祸。
