内存对齐是为了让CPU单周期读取对象头和字段，通过8字节对齐避免多次内存访问、硬件异常或性能降级，并支撑指针压缩与伪共享防护，其填充量需实测确认。
内存对齐是为了让CPU单周期读取对象头和字段
64位系统上，CPU寄存器和内存总线通常按8字节或16字节块访问。如果一个 long 字段起始地址是 0x1003（非8的倍数），CPU就得先读 0x1000–0x1007，再读 0x1008–0x100F，最后拼出这8字节——多一次内存访问，延迟翻倍。HotSpot强制对象起始地址是8字节对齐，就是确保任意字段只要按类型长度自然对齐，就能被单次加载。
不对齐会触发硬件异常或 silently slow down
某些ARM64平台（如AWS Graviton）或旧款x86 CPU在访问未对齐的 double 或 long 时直接抛 BusError；更多现代CPU虽能容忍，但会降频执行、禁用某些向量化指令。JVM不冒险——它在分配时就靠填充字节（padding）把对象大小拉到8字节整数倍，避免运行时踩坑。
指针压缩（CompressedOops）依赖对齐才能生效
-XX:+UseCompressedOops 能把Klass Pointer从8字节压到4字节，前提是堆内存起始地址本身是8字节对齐的，且对象布局满足“低3位为0”的寻址前提。一旦对象没对齐，JVM要么拒绝启用压缩（见日志中 Failed to use compressed oops），要么退化为全宽指针——内存占用瞬间涨30%以上。这也是为什么堆大小超过32GB时，压缩指针自动失效：地址空间高位无法再用3位补零对齐。
对齐填充不是浪费，而是防止伪共享（False Sharing）
多个线程频繁修改同一缓存行（通常是64字节）里的不同字段，会导致L1 cache反复无效化。HotSpot的对齐策略会让每个对象至少占16字节（Object最小布局），配合字段重排（如把 volatile long 和普通 int 分开），天然拉开热点字段距离。如果你在写高频更新的统计对象，手动加 @Contended 注解，底层仍依赖这套对齐机制才起作用。
真正容易被忽略的是：对齐规则在对象创建时就固化了，后续字段增减、父类变更、甚至JDK小版本升级（比如从17.0.1到17.0.2）都可能改变填充量。别信“估算公式”，用 ClassLayout.parseInstance(obj).toPrintable() 实测才是唯一可靠方式。
