伪共享的“假”在于多个线程合法修改不同变量却因缓存行对齐被硬件强制耦合，导致频繁缓存失效；@Contended需配合JVM参数和正确用法才生效，手动填充则须精准对齐64字节边界。
伪共享到底在“假”什么？
伪共享不是代码写错了，而是多个线程在“合法地、互不干扰地”改不同变量，却因为 CPU 缓存行（Cache Line）这个硬件机制被强行绑在一起——只要两个 long 字段在内存里挨得太近（比如相距不到 64 字节），它们就极可能落在同一个缓存行里。一个线程改 a，另一个线程读/写 b，就会触发 MESI 协议下的缓存失效与重加载，白白消耗上百个 CPU 周期。
典型症状是：线程数翻倍，吞吐量不升反降；热点方法 CPU 使用率高但 IPC（每周期指令数）很低；用 perf stat -e cache-misses,cache-references 或 Intel VTune 能看到异常高的缓存未命中率。
@Contended 注解怎么填才真正生效？
加了 @Contended 不等于就解决了伪共享——它默认是“哑”的，JVM 根本不认。必须同时满足三个条件：
- 使用
jdk.internal.vm.annotation.Contended（Java 8+，注意不是过时的sun.misc.Contended） - 启动时加上 JVM 参数：
-XX:+UnlockExperimentalVMOptions -XX:+EnableContended（-XX:-RestrictContended在较新 JDK 中已废弃，以EnableContended为准） - 字段需是实例字段（
static字段不支持）
示例：
import jdk.internal.vm.annotation.Contended;
public class Metrics {
@Contended private long successCount;
@Contended private long failCount;
}
这样编译后，JVM 会在每个字段前后插入填充字节，确保它们各自独占一个 64 字节缓存行。
字段级 vs 类级 @Contended，别乱套用
类级标注（@Contended 加在 class 上）会让整个对象实例字段区两端都填充，相当于给整块字段内存“包边”，开销大且不精准；字段级才是日常该用的方式。
还有一个少有人知但实用的技巧：@Contended("group1") 可以把多个字段归入同一争用组，它们在内存中连续排列，但与其他字段隔离——适合一组强关联、又需避免跨核竞争的计数器，比如 readCount 和 writeCount。
容易踩的坑：
- 误用
static字段 +@Contended→ 完全无效，JVM 忽略 - 忘了加 JVM 参数 → 编译通过、运行无报错、但填充不发生，伪共享照旧
- 在非底层框架（如业务 DTO）滥用 → 每个字段多占 64 字节，对象膨胀严重，GC 压力上升
不用 @Contended 怎么办？手动填充也得讲逻辑
如果不能用内部 API（比如受限于 JDK 版本或合规要求），就得手动填充。核心原则不是“随便加几个 long”，而是确保目标字段的起始地址对齐到 64 字节边界。
例如，想让 value 独占缓存行：
public class PaddedCounter {
// 7 个 long = 56 字节前置填充
private long p1, p2, p3, p4, p5, p6, p7;
private volatile long value;
// 7 个 long = 56 字节后置填充（可选，防后续字段挤进来）
private long q1, q2, q3, q4, q5, q6, q7;
}
注意：字段顺序影响内存布局，JVM 默认按声明顺序分配；若开启 -XX:+UseCompressedOops（默认开启），对象头是 12 字节，填充计算要从偏移 12 开始算。
更稳妥的做法是用 -XX:+PrintFieldLayout 查看实际布局，而不是靠经验猜。
真正难的不是填多少字节，而是判断“谁该被隔离”——高频更新的计数器、RingBuffer 的生产者/消费者指针、Disruptor 中的序列号字段……这些才是填充的优先级目标。盲目给所有字段加 padding，只会让问题从性能变成内存。
