false sharing 会因缓存行争用拖慢cpu：当线程修改同一缓存行内不同变量时，mesi协议频繁使对方缓存行失效；java中字段紧凑排列易触发该问题，需用@contended或手动填充确保64字节对齐。
False Sharing 为什么会让看似独立的变量互相拖慢
CPU 缓存行（cache line）是硬件最小读写单位，通常是 64 字节。当两个线程分别修改同一缓存行内的不同变量时，即使逻辑上毫无关系，也会因缓存一致性协议（如 MESI）反复使对方缓存行失效——这就是 False Sharing。
典型现象：多线程计数器性能远低于预期，perf 显示大量 cache-misses 或 LLC-stores-misses；用 jmh 做基准测试时，并发吞吐不随线程数线性增长，甚至下降。
- Java 对象字段默认紧凑排列，
long a;和long b;很可能落在同一缓存行内 - 即使加了
volatile或用AtomicLong，也不能阻止缓存行级别的争用 - JVM 不会自动对齐字段到缓存行边界，必须手动干预
如何用 @Contended 让字段独占缓存行
@sun.misc.Contended 是 JDK 8 引入的、专为缓解 False Sharing 设计的注解，但默认关闭，需启动时加参数：-XX:-RestrictContended（JDK 9+ 默认开启，但部分 OpenJDK 构建仍需显式启用）。
它让 JVM 在对象布局中插入填充字段（padding），把标注字段“撑开”到独立缓存行。
立即学习“Java免费学习笔记（深入）”；
- 只对类字段有效，不能用于局部变量或数组元素
- 必须配合 JVM 参数，否则完全无效；可用
java -XX:+PrintFieldLayout YourClass验证是否生效 - 注意包名限制：非
jdk.包下使用需加-XX:ContendedPaddingWidth=64，否则默认只 padding128字节（过度对齐反而浪费内存）
@sun.misc.Contended
public class Counter {
public volatile long value = 0;
}
不用 @Contended 怎么手动对齐字段
如果不能用 @Contended（比如受限于 JDK 版本或生产环境策略），就得靠“填充字段”硬凑 64 字节边界。核心是：让目标字段前后的字段总大小 ≥ 64 字节，且自身起始地址 % 64 == 0。
常见错误是只在字段后加 long p1…p7，却忽略对象头（12 字节）、对齐填充、以及字段本身偏移——实际偏移得靠 Unsafe.objectFieldOffset() 或 Unsafe.arrayBaseOffset() 查。
- 推荐方式：用
long数组 +Unsafe定位，例如value存在data[0]，再确保data起始地址对齐（通过分配大数组 + 取模跳过前部） - 更稳妥的是用
jdk.internal.vm.annotation.Contended（JDK 9+）替代旧版@sun.misc.Contended，语义更清晰 - 别依赖
SerialGC下的固定对象布局——G1/ZGC 会移动对象，偏移不固定
64 字节对齐在数组/队列场景中的陷阱
数组元素天然连续，long[] arr 中相邻元素大概率共享缓存行。RingBuffer、MPSC 队列等高性能结构若直接按索引写入，极易触发 False Sharing。
解决不是简单给每个元素 padding，而是重构访问模式：用单个写指针 + 多个读指针，或采用“一写一读”隔离设计；若必须多写，就让每个写线程独占一段连续空间（如分段 buffer），段之间留足 64 字节间隙。
- 不要在循环里对
arr[i]做volatile写——i 相邻就等于缓存行相邻 -
VarHandle的setOpaque/setRelease无法规避 False Sharing，只是弱化内存序 - 用
ByteBuffer.allocateDirect()分配的堆外内存，同样受缓存行影响，对齐逻辑不变
False Sharing 不是 Java 独有，但 Java 因对象布局不可控、缺乏标准对齐语法，比 C/C++ 更容易踩坑。真正关键的不是“加了多少 padding”，而是确认目标字段在运行时确实独占缓存行——这一步，绕不开 PrintFieldLayout 或 Unsafe 偏移校验。
