8字节对齐是64位硬件强制要求，为避免跨总线读取；真正增加内存开销的是对齐导致的内部碎片，小对象因向上取整至8倍数而填充冗余字节，字段越小零散、填充比例越高。
8 字节对齐本身不产生“副作用”，它是现代 64 位系统中兼顾硬件效率与实现简洁性的强制约定。真正影响小对象内存占用的，不是对齐本身，而是对齐带来的 内部碎片（Internal Fragmentation）——即对象末尾为满足 8 字节边界而填充的无用字节。
为什么必须是 8 字节？不是更小，也不是更大
CPU 外部总线通常以 8 字节（64 位）为单位读取内存。若一个 long（8 字节）存放在地址 9 开始处，CPU 需要两次访存（读地址 8 和 16），再拼接数据；而放在地址 8 开始处，一次即可完成。某些 ARM 架构甚至直接报对齐异常。因此，JVM 在 64 位下将所有对象起始地址强制对齐到 8 的倍数，这是硬件要求，不是可选项。
内部碎片如何在小对象上放大
HotSpot JVM 要求每个对象总大小向上取整到 8 字节的倍数。这意味着：
- 空对象：8 字节 → 实际占 8 字节（无填充）
-
byte a;：对象头 12 字节（开启压缩指针）+ 1 字节字段 = 13 字节 → 向上取整为 16 字节 → 填充 3 字节 -
boolean a; byte b;：12 + 1 + 1 = 14 → 填充 2 字节 → 总 16 字节 -
int a;：12 + 4 = 16 → 刚好对齐，无填充 -
long a;：12 + 8 = 20 → 填充 4 字节 → 总 24 字节
可见，字段越小、越零散，填充比例越高。一个仅含 1 字节业务数据的对象，实际开销达 16 字节，填充率 18.75%；百万个这样的对象，就多占约 8MB 内存。
字段顺序能减少填充，但不能消除它
JVM 按照字段声明顺序（配合默认分配策略）布局实例数据。合理排序可压缩填充：
-
byte a; int b;→ 头 12 + a(1) + 填充 3 + b(4) = 20 → 填充 4 字节 → 总 24 字节 -
int b; byte a;→ 头 12 + b(4) + a(1) + 填充 3 = 20 → 仍为 24 字节 -
long c; byte a;→ 若先放long，则头 12 + c(8) = 20 → 填充 4 → a 只能从 24 开始 → 总 32 字节；若把byte放最前，头 12 + a(1) + 填充 3 + c(8) = 24 → 总 32 字节 —— 此时顺序不影响总大小
关键点：填充只发生在对象末尾（保证整体大小是 8 的倍数），中间字段间的空隙由字段自身对齐要求决定（如 long 必须从 8 的倍数地址开始），但最终对象大小仍需整体对齐。
压缩指针让内部碎片“变小但更常见”
启用 -XX:+UseCompressedOops 后，对象头从 16 字节降至 12 字节，直接降低基础开销：
- 未开启：1 字节字段 → 16（头）+ 1 + 7 填充 = 24 字节
- 开启后：12 + 1 + 3 填充 = 16 字节
虽然单个对象节省了 8 字节，但因头变小，更多小对象会落入「12–16」区间，反而更容易触发 16 字节对齐（而不是跳到 24）。也就是说，压缩指针没消除碎片，只是把碎片“挪”到了更小的尺度上，对海量小对象依然敏感。
