伪共享问题出在CPU缓存行对齐失效环节：多个线程修改同一缓存行内不同变量，引发不必要的缓存同步，导致吞吐下降而不报错。
Java伪共享到底在哪个环节出问题
伪共享本质是CPU缓存行（cache line）对齐失效导致的性能损耗：多个线程频繁修改位于同一缓存行内的不同变量，引发不必要的缓存同步（false invalidation）。它不报错、不崩溃，只悄悄拖慢并发吞吐——尤其在高争用、低延迟场景下，AtomicLong计数器或环形缓冲区（如Disruptor）里相邻字段常中招。
关键判断：如果你观察到线程数增加但吞吐不升反降，且热点方法里有多个独立的volatile字段或原子类型紧挨着定义，大概率是伪共享在作祟。
@Contended注解怎么用才生效
@Contended是JDK 8u20+引入的解决方案，但它默认关闭，且仅对特定JVM参数和类加载路径有效。不配参数，加了也白加。
- 必须启用JVM参数：
-XX:+UseContended（JDK 9+默认开启，但JDK 8必须显式加） - 若类不在
java.*或sun.*包下，需额外指定-XX:ContendedPaddingWidth=64（推荐值，对应主流CPU缓存行长度） - 注解可加在类、字段或内部类上；加在字段上时，该字段会被单独隔离到新缓存行，前后自动填充
- 注意：使用
@Contended的类会被JVM特殊处理，可能导致类加载变慢，不适合高频动态生成的类
示例：
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
@Contended
public class Counter {
public volatile long value;
}
此时value前后会插入约128字节填充（取决于ContendedPaddingWidth），确保它独占缓存行。
手动填充字段比@Contended更可控吗
手动填充（如定义7个long字段把目标字段隔开）看似简单，但实际更难维护，且容易因JVM字段重排序或压缩Oops失效。
- JVM可能对未使用的填充字段做优化（尤其是逃逸分析后），导致填充“塌缩”
- 32位JVM或开启
-XX:+UseCompressedOops时，对象头大小变化会影响字段偏移，手动计算的填充量可能不准 -
@Contended由JVM保证填充语义稳定，且支持运行时开关调试，比硬编码填充字段更可靠 - 如果无法升级JDK或受限于容器环境（如某些Alpine镜像默认无JDK 8u20+），才考虑手动填充，并务必用
Unsafe.objectFieldOffset()验证字段真实偏移
伪共享优化后为什么反而变慢了
常见反模式：在不该隔离的地方强行隔离，或者隔离粒度失控。
- 过度使用
@Contended会导致对象体积暴涨（一个@Contended字段可能让对象多占256+字节），加剧GC压力和内存带宽消耗 - 缓存行隔离只对“高频率写、低频率读、彼此无依赖”的字段有效；若两个字段常被一起读（如
x和y构成坐标），强行拆开反而破坏局部性，降低L1缓存命中率 - 注意JVM版本差异：JDK 10+对
@Contended做了填充策略优化，但早期版本填充更激进，实测前建议用jol（Java Object Layout）工具看真实内存布局
真正要盯住的，不是“有没有加@Contended”，而是“改完之后，L3缓存失效次数是否下降、每核IPC是否回升”——这些得靠perf stat -e cache-misses,cache-references这类底层指标验证。
伪共享不是靠加个注解就一劳永逸的事，它要求你既懂CPU缓存行为，又得信得过自己看到的内存布局和性能计数器。稍不注意，优化就变成负优化。
