java对象内存对齐本质是jvm为提升cpu访问效率采用的底层布局策略，字段顺序影响填充量，宽字段前置可减少padding；对象头12字节（压缩指针开启），整体8字节对齐；boolean等基本类型实际占用固定字节，不对齐会导致缓存行利用率下降、gc压力增大及伪共享风险。
Java基本数据类型的内存对齐，本质是JVM在堆上分配对象时，为提升CPU访问效率而采取的底层布局策略。它不改变语法行为，但直接影响对象大小、内存占用和缓存行利用率——尤其在高并发或大数据量场景下，这种“看不见的开销”可能成为性能瓶颈。
字段顺序决定填充量
字段在类中声明的顺序，直接决定JVM插入多少填充字节。JVM按声明顺序依次排布字段，并确保每个字段起始地址满足其对齐要求（如long需8字节对齐）。
- 推荐把宽字段（long/double）放在前面，窄字段（byte/boolean/short）靠后，可显著减少padding
- 反例：
byte a; long b; int c;→ a占1字节，b需跳到第8字节起始（填7字节），c再跳到16字节起始（填4字节），总大小至少24字节 - 优化后：
long b; int c; byte a;→ b占8字节，c占4字节，a占1字节，末尾补7字节对齐到24字节，但实际只需补3字节到24？不对：8+4+1=13 → 补3字节到16字节即可（因整体必须8字节对齐），总大小仅16字节
对象头与整体8字节对齐
每个Java对象都有对象头（Header），包含Mark Word和类型指针。在64位JVM开启压缩指针（默认开启）时，对象头共12字节（Mark Word 8字节 + 压缩类指针 4字节）；未开启则为16字节（各8字节）。但无论头多大，整个对象占用内存必为8字节的整数倍。
- 空对象：对象头12字节 → 补4字节 → 占16字节
- 仅含1个boolean：头12字节 + boolean 1字节 = 13 → 补3字节 → 占16字节
- 含8个boolean：头12字节 + 8字节 = 20 → 补4字节 → 占24字节（不是16）
- 注意：boolean在HotSpot中始终占1字节，不打包，也不共享字节位
基本类型真实占用 ≠ 语义宽度
Java规范只规定了类型的取值范围和运算行为，不强制存储大小。但HotSpot JVM有明确实现：
- boolean：逻辑上1位，实际占1字节（8位），不可压缩
- byte/char/short：分别固定占1、2、2字节，无例外
- int/float：统一占4字节
- long/double：统一占8字节（64位JVM下，32位JVM也如此）
- 数组元素严格按类型对齐，且整个数组对象本身也满足8字节对齐
对齐失效的代价不只是空间浪费
当字段未对齐（如long跨两个缓存行），CPU访问可能触发两次内存读取，甚至引发总线锁或异常（取决于硬件）。虽然JVM自动对齐避免了这类错误，但不当布局仍带来隐性成本：
- 更多内存占用 → 更频繁GC → STW时间增加
- 对象变大 → 缓存行利用率下降 → CPU L1/L2缓存命中率降低
- 字段分散 → 热字段与冷字段混在同一缓存行 → 伪共享（false sharing）风险上升
