java对象内存布局由对象头（含mark word和klass pointer）、实例数据（字段值，按大小重排以优化填充）和对齐填充（补至8字节倍数，保障cpu缓存行效率）三部分构成；数组对象头额外包含长度字段，@contended需配合jvm参数启用才生效。
对象对齐与填充不是“省空间”的技巧，而是直接影响 CPU 缓存行（Cache Line）加载效率的关键控制点。不加干预时，JVM 默认的字段重排 + 8 字节对齐，大概率导致热点字段跨缓存行、多个线程写入同一缓存行（伪共享），最终拖慢吞吐、抬高延迟。
怎么确认你的对象被拆到了多个缓存行里？
靠猜不行，得用 jol-core 看真实内存布局：
- 运行
ClassLayout.parseClass(YourClass.class).toPrintable()，输出中重点关注“instance data”字段偏移（offset）和总大小（size） - 如果某个字段 offset 是 56，而它本身占 4 字节（比如
int），那它就横跨了第 0 行（0–63）和第 1 行（64–127）——因为 56+4=60，还在第 0 行；但如果 offset 是 60、字段是long（8 字节），60+8=68 → 跨行 - 数组对象还要额外注意：对象头 + 数组长度（4 字节）已占 16 字节（64 位 + 压缩指针），第一个元素从 offset=16 开始，若元素类型是
long，则下标 7 的元素起始 offset = 16 + 7×8 = 72 → 已跨缓存行
@Contended 注解为什么不能直接加在普通字段上生效？
默认情况下 @Contended 是被 JVM 忽略的，必须显式开启参数：-XX:+UnlockExperimentalVMOptions -XX:+RestrictContended（JDK 9+）。否则即使加了注解，JVM 也不会插入填充字段。
- 加在类上：整个类实例被强制对齐到 128 字节边界，并在头部/尾部插入填充，隔离整个对象
- 加在字段上：仅对该字段前后插入填充（默认 128 字节），但需配合分组名（如
@Contended("groupA")）才能让同组字段挤在一起、不同组隔开 - 没开参数或没分组，
@Contended形同虚设，jol 输出里看不到额外 padding
手动字段重排比 @Contended 更可控，但容易翻车在哪？
字段重排依赖 JVM 的 -XX:+CompactFields（默认开启），但它只在开启压缩指针（-XX:+UseCompressedOops）时才真正生效。关掉压缩指针后，字段重排逻辑可能退化，甚至出现更差的布局。
- 安全顺序：先排 8 字节字段（
long、double、引用），再排 4 字节（int、float），再排 2 字节（short）、1 字节（byte、boolean） - 危险操作：把
boolean放最前，后面紧跟long→ JVM 可能把它塞进long前面的空隙，但该空隙是否真存在，取决于前面有没有其他字段“挡住” - 验证必须跟上：每次改完字段顺序，都要跑 jol，看 offset 是否真的收敛在单个缓存行内（例如 0–63 或 64–127）
为什么 padding 到 64 字节还不够，有时得 pad 到 128？
现代多核 CPU 中，L1/L2 缓存行确实是 64 字节，但某些场景下，硬件预取器或特定微架构（如 Intel Ice Lake 后）会以 128 字节为单位做预取；更重要的是，@Contended 默认填充就是 128 字节，这是为了彻底切断相邻对象间的伪共享风险。
- 单线程热点字段：64 字节对齐足够
- 多线程高频更新字段（如计数器、状态标志）：必须确保它独占一个缓存行，且前后无其他可写字段 → 用
@Contended或手动 pad 至 128 字节更稳妥 - 注意：padding 过多会增加 GC 压力和堆内存占用，别盲目全量 pad，只对真正高频读写的字段做
真正难的不是算出 padding 多少字节，而是识别哪些字段构成“访问热点”，以及它们是否被同一线程/核心密集使用。jol 和 -XX:+PrintGCDetails 只能告诉你“是什么”，不能告诉你“为什么慢”——得结合 async-profiler 抓取 cache-misses 指标，才能闭环验证对齐优化是否真的起了作用。
