8字节对齐能减少CPU读取次数，是因为它确保任意8字节字段（如long、double）起始地址满足address%8==0，从而单次加载即可完成读取；否则跨边界未对齐访问需多次读取再拼接，降低性能甚至引发ARM平台SIGBUS错误。
为什么 8 字节对齐能减少 CPU 读取次数
现代 CPU 从内存读取数据时，一次能加载的最小单位通常是缓存行（cache line），主流 x86-64 架构默认是 64 字节。但更底层的访问粒度取决于总线宽度和对齐要求：未对齐访问可能触发多次内存操作。比如一个 long 字段（8 字节）若跨两个 8 字节边界（如地址 15～22），CPU 就得读两次 8 字节再拼接——这比一次对齐读取慢得多。
JVM 强制对象以 8 字节为单位对齐，本质是让所有字段起始地址满足 address % 8 == 0，这样任意 8 字节字段都能被单次载入寄存器。即使硬件支持未对齐访问（如 x86），它仍会降低吞吐量；而 ARM 等架构可能直接报 SIGBUS。
- 对象头中
MarkWord和类型指针必须原子读写，8 字节对齐保障了 volatile long/double 的原子性语义 - 数组元素、对象实例字段、甚至填充字节（
Padding）都服务于这一目标，不是“浪费”，而是避免运行时拆分读取 - 用
jol-cli.jar查看java.lang.Long时能看到value字段偏移量是16，正好是 8 的倍数
怎么用 jol-cli 验证字段偏移与对齐效果
jol-cli 是最直接观察 JVM 对象布局的工具，它能暴露字段真实偏移、填充位置和整体大小。执行命令：java -jar jol-cli.jar internals ClassName 即可输出结构。
例如定义一个类：
class Person {
int age; // 4 字节
double height; // 8 字节
}
运行后你会看到 height 偏移是 16，而非紧接 age 后的 4——中间插入了 4 字节 alignment/padding gap。这是因为 JVM 按照字段大小降序排列（8 > 4 > 2 > 1），并确保每个字段起始地址对齐到自身宽度，同时整体对象大小保持 8 字节整数倍。
- 字段顺序影响填充量：把
double放前面可减少 padding；反之会多出 4 字节空洞 - 开启压缩指针（
-XX:+UseCompressedOops）时，对象头从 16 字节缩为 12 字节，但对齐规则不变，仍强制 8 字节粒度 - 不要依赖
sizeof或Unsafe.objectFieldOffset直接推算——它们返回的是 JVM 实际布局，不是源码声明顺序
对齐填充（Padding）不是无意义的“补零”
Padding 是 JVM 在对象末尾或字段间插入的空白字节，目的不是凑数，而是维持两条硬约束：字段自身对齐 + 整体对象大小是 8 的倍数。它直接影响 GC 扫描效率和缓存局部性。
比如一个只有两个 int 字段的对象（共 8 字节），理论上无需 padding；但若父类留有 4 字节空隙，子类第一个字段又要求 8 字节对齐，JVM 就会在中间插 4 字节——这是为了防止后续对象分配时，该字段跨 cache line。
- 填充发生在编译期确定的布局阶段，不随运行时值变化
- 过度填充会增加堆内存压力，尤其在高频小对象场景（如事件、DTO）下，累计开销明显
- 用
-XX:ObjectAlignmentInBytes=16可扩大对齐粒度，但会显著增加平均对象体积，通常只在特定 NUMA 或伪共享优化场景使用
容易被忽略的陷阱：volatile long/double 的对齐失效
Java 规范要求 volatile long 和 volatile double 的读写必须原子，而硬件仅保证自然对齐下的原子性。如果字段没对齐（比如因错误字段排序导致偏移为 12），JVM 无法靠指令保证原子——此时可能产生撕裂读（torn read）。
这种问题在非 x86 平台更危险：ARMv8 默认禁止未对齐原子操作，会直接 crash。即便在 x86 上，性能也下降明显。
- 不要手动用
Unsafe修改字段偏移来“节省空间”——破坏对齐等于放弃 JMM 保证 - 继承链中父类字段排布会影响子类字段对齐，尤其是当父类结尾是 4 字节字段时，子类首个 8 字节字段可能被迫插入 padding
- 用
jol-cli检查关键 volatile 字段的 offset 是否为 8 的倍数，是最简单有效的验证方式
