对象真实大小需对齐至8字节整数倍，由对象头（默认12字节）与实例数据之和向上取整决定，填充不可消除但可最小化，字段重排、类型优化及指针压缩是关键手段。
JVM 分析对象内存对齐与填充，核心是看清“对象头 + 实例数据”总大小是否为 8 字节整数倍；不是为了消除填充，而是让填充最小化——通过字段重排、类型调整和指针压缩，把原本散落的空隙收拢、压平。
对象真实大小 ≠ 字段字节数之和
很多开发者误以为两个 int 字段（各 4 字节）的对象只占 8 字节。实际上： - 对象头默认 12 字节（64 位 JVM 开启指针压缩时） - 两个 int 占 8 字节 → 头 + 数据 = 20 字节 - 向上对齐到 8 的倍数 → 补 4 字节填充 → 总大小 24 字节 这就是典型的“字段小、开销大”。用 JOL（Java Object Layout） 工具可实测验证：
- 添加依赖：
org.openjdk.jol:jol-core - 调用
ClassLayout.parseClass(User.class).toPrintable() - 输出含每段偏移、大小、填充位置，一目了然
字段顺序重排是降低填充的关键手段
JVM 不按代码声明顺序存放字段，而是按宽度降序排列（long/double → int/float → short/char → byte/boolean），相同宽度字段连续存放。这样能显著减少内部碎片：
- 坏例子：
byte a; long b; int c;→ 布局为 a(1) + padding(7) + b(8) + c(4) = 至少 20 字节（头 12 + 数据 8 → 总 24） - 好例子：
long b; int c; byte a;→ b(8) + c(4) + a(1) + padding(3) = 数据区仅 16 字节，总大小更可控 - 子类窄字段可插入父类空隙（需
-XX:+CompactFields，默认开启）
指针压缩与字段类型选择直接影响对齐结果
引用类型字段在开启指针压缩（-XX:+UseCompressedOops，默认开启）时只占 4 字节，否则占 8 字节。这会连锁影响后续字段对齐：
- 一个
String name+ 一个int id：压缩下为 4 + 4 = 8 字节数据区；未压缩则为 8 + 4 = 12 字节 → 后者更容易触发额外填充 - 用
int替代Integer，避免引用+空对象头双重开销 - 布尔值密集场景考虑
BitSet或位运算打包，而非一堆boolean字段
对齐填充本身不可删除，但可预测和利用
对齐填充没有语义，不参与 GC，也不影响逻辑，但它决定了缓存行利用率和伪共享风险：
- CPU 缓存行通常是 64 字节，若一个对象占 24 字节，3 个对象就能填满一行；若因字段乱序导致单对象达 40 字节，就只剩 1 个半对象空间
- 高并发计数器类应把
volatile long count单独拆成独立对象，或加@Contended注解隔离，防止被其他字段“挤”进同一缓存行引发伪共享 - 填充大小 =
(对象头 + 实例数据) % 8 == 0 ? 0 : 8 - ((对象头 + 实例数据) % 8)，可写脚本批量估算
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
