伪共享是多核cpu缓存一致性导致的性能问题：同一缓存行（64字节）内不同变量被多线程修改时，引发频繁缓存行无效化；java中典型表现为相邻long字段“连坐”，可用@contended注解或手动long填充解决。
什么是伪共享？CPU缓存行和 long 字段的“连坐”问题
伪共享不是 Java 独有，而是多核 CPU 缓存一致性协议下的硬件级现象：当两个线程分别修改**同一缓存行（通常是 64 字节）内不同变量**时，即使逻辑上毫无关系，也会因缓存行被反复无效化（Invalidation）而严重拖慢性能。
Java 中最典型场景是高并发计数器类里相邻定义的 long 字段——比如 value1 和 value2 在对象内存中紧挨着，很可能落在同一缓存行。一个线程改 value1，另一个线程读/写 value2，就会触发整行同步，造成“假竞争”。
- 常见错误现象：
AtomicLong或volatile long字段在多线程下吞吐量远低于预期，且 CPU 缓存失效（LLC-misses）指标异常高 - 不是 GC 问题、不是锁争用，
jstack看不到阻塞，但perf stat -e cache-misses,cache-references能暴露缓存行抖动 - 64 位 JVM 下，
long和double占 8 字节，但 JVM 不保证字段对齐；默认布局下多个long很容易挤进同一缓存行
@Contended 怎么用？必须加 JVM 参数才生效
@Contended 是 JDK 8 引入的注解，作用是在字段前后插入填充字节（padding），强行把目标字段独占一个缓存行。但它默认不启用，否则会增大对象体积、浪费内存。
必须显式开启 JVM 参数：-XX:+UnlockExperimentalVMOptions -XX:+RestrictContended（JDK 8u20+）或 -XX:+UnlockDiagnosticVMOptions -XX:+RestrictContended（部分旧版本）。漏掉任一参数，注解完全被忽略。
立即学习“Java免费学习笔记（深入）”；
- 只对实例字段有效，静态字段不支持
@Contended - 字段需声明为
private（JDK 9+ 要求更严，建议始终 private） - 示例：
@sun.misc.Contended private volatile long counter;
- 注意包名：
@sun.misc.Contended是实际可用的，不是java.lang.Contended（后者不存在）
不用 @Contended 怎么手动对齐？靠 long 填充字段
如果不能开 JVM 参数（如生产环境受限），或者用的是 JDK 7，就得手动填充。核心思路：让关键字段前后至少预留 56 字节（64 − 8），确保它独占缓存行。
常用手法是定义 7 个无用的 long 字段（7 × 8 = 56 字节）包围目标字段。虽然丑，但稳定、无依赖、全 JDK 兼容。
- 填充位置很重要：必须放在同一对象内，且紧邻目标字段前后；跨字段或跨对象无效
- 示例结构：
private volatile long p1, p2, p3, p4, p5, p6, p7; // 前置填充 private volatile long value; // 目标字段 private volatile long q1, q2, q3, q4, q5, q6, q7; // 后置填充
- 不要用
byte[56]填充——数组对象本身有 header 开销，且可能被 JVM 优化掉；long字段最可靠 - 填充后对象大小会明显变大（+112 字节），对堆内存敏感场景要权衡
伪共享真的存在吗？怎么验证你修对了
别信理论，得测。伪共享的影响只有在高并发、高频更新、字段又恰好“不幸相邻”时才会爆发。很多所谓“修复”其实没效果，因为根本没触发伪共享。
- 验证前提：用
Unsafe或FieldLayout工具（如jdk.internal.vm.annotation.Contended的配套工具）确认字段实际偏移量，看是否真落在同一缓存行（64 字节对齐边界） - 压测对比：用 JMH 写两个版本（带填充 vs 不带），线程数 ≥ CPU 核心数，操作频率 ≥ 百万次/秒，观察吞吐量提升是否显著（常达 2–5 倍）
- 容易踩的坑：测试时用了单线程、或字段访问间隔太长（缓存行已自然失效）、或 JVM 没开
-XX:+UseParallelGC等影响缓存局部性的选项，结果看不出差异 - 真实复杂点在于：现代 JVM（如 ZGC、Shenandoah）和 CPU（ARM64、Intel Ice Lake 后）对伪共享的缓解能力增强，但不等于消失——尤其在低延迟交易、高频日志聚合等场景，仍需手动干预
