多线程修改相邻字段变慢是因伪共享：同一缓存行内不同变量被多线程修改，触发MESI协议频繁失效与重载，导致吞吐下降、延迟毛刺；常见于AtomicLong数组、RingBuffer等场景。
为什么多线程修改相邻字段会变慢？
因为 CPU 缓存以缓存行（通常 64 字节）为单位加载数据，当两个线程分别修改同一缓存行内的不同变量时，即使逻辑上互不干扰，也会因缓存一致性协议（如 MESI）频繁使彼此的缓存行失效，反复从内存或其它核重载——这就是伪共享。它不报错，但吞吐骤降、延迟毛刺明显，尤其在高并发计数器、RingBuffer、Disruptor 等场景中极易触发。
常见错误现象：AtomicLong 数组批量更新性能远低于预期；volatile 字段读写延迟突增；JMH 基准测试结果抖动大且与线程数非线性相关。
- 别用
long a, b;这种紧挨着声明的方式存放高频更新的独立状态 - 确认是否真被伪共享拖累：用
perf record -e cache-misses,instructions或 JFR 的CompilerInlining+CacheLineMisses事件辅助定位 - HotSpot 8u202+ 默认禁用
@Contended，需显式加 JVM 参数：-XX:-RestrictContended
@Contended 注解怎么填才生效？
@Contended 不是“加了就自动隔离”，它只对类字段起作用，且依赖 JVM 启用和字段布局策略。默认情况下，HotSpot 忽略该注解；即使启用，也仅对被标记字段前后插入填充字节（padding），而非整个对象重排。
使用场景：适用于明确知道哪些字段会被不同线程高频独占更新，且能接受对象内存占用上升（典型增加 128~256 字节/字段）。
立即学习“Java免费学习笔记（深入）”；
- 必须用
sun.misc.Contended（JDK 8）或jdk.internal.vm.annotation.Contended（JDK 9+），不能自定义同名注解 - 字段需是实例字段，静态字段无效；建议配合
-XX:ContendedPaddingWidth=64显式设为缓存行宽 - 示例：
@jdk.internal.vm.annotation.Contended private volatile long counter;
- 注意类加载顺序：含
@Contended的类不能被 bootstrap classloader 加载（否则抛UnsupportedOperationException）
不用 @Contended 怎么手动避免伪共享？
手动填充更可控、兼容性更好，尤其适合 JDK 7 或无法开启 @Contended 的生产环境。核心思路是确保热点字段独占一个缓存行，即前后至少预留 64 字节空间。
参数差异：填充字段类型选 long（8 字节）最省事，7 个就够（56 字节），再加一个 byte 补齐；用 long[8] 数组虽直观但 GC 压力略高。
- 推荐写法：
private volatile long p0, p1, p2, p3, p4, p5, p6, p7; // 56 字节前置填充 private volatile long value; private volatile long q0, q1, q2, q3, q4, q5, q6, q7; // 56 字节后置填充
- 别用
Object或String填充——它们不保证内存连续，且可能被 JVM 优化掉 - 字段名带
p/q前缀是社区惯例，方便识别填充字段，不影响功能 - 如果字段本身是数组（如
long[]），注意数组对象头 + length 字段也可能挤占同一缓存行
伪共享问题在哪些地方容易被忽略？
它藏得深：不在堆栈里报错，不进日志，监控指标也看不出直接关联。最容易被当成“机器性能波动”或“GC 问题”误判。
性能影响不是线性的——2 个线程可能只慢 20%，但 8 个线程可能慢 5 倍以上；而换一台 L3 缓存更大的机器，问题又暂时消失，导致复现困难。
- Disruptor 的
RingBuffer、LMAX 框架的序列号字段都靠手动填充规避伪共享，不是玄学而是实测刚需 - Log4j2 的
AsyncLogger和 Netty 的Recycler内部也大量使用填充技术 - 注意 JIT 优化：某些填充字段可能被逃逸分析判定为无用而消除，加
@SuppressFBWarnings("UWF_UNWRITTEN_FIELD"类注解无助于阻止，得靠实际访问（如构造时赋初值）保活
真正麻烦的是：你得先想到它存在，再用工具验证，最后还得权衡内存膨胀和性能提升的 trade-off。很多团队调优到最后才发现，瓶颈不在算法，而在 CPU 缓存行怎么对齐。
