怎么通过分析 Java 的伪共享（False Sharing）问题优化多核 CPU 下的同步变量设计-java教程-PHP中文网

伪共享是多核CPU缓存行冲突导致的性能问题：当两线程高频修改同一64字节缓存行内不同字段时，因MESI协议频繁无效化缓存行，引发吞吐下降、缓存未命中飙升；需通过字段填充（如byte[56]）、显式布局或隔离分配使敏感字段间隔≥64字节来避免。

怎么通过分析 java 的伪共享（false sharing）问题优化多核 cpu 下的同步变量设计

伪共享不是代码写错了，而是变量在内存里“站得太近”，被 CPU 当成一个整体反复刷新，导致多核性能不升反降。直接上结论：**只要两个高频更新的 volatile 字段或原子类实例在同一个缓存行（通常是 64 字节）内，就极可能触发伪共享；解决它不能只靠加锁或换数据结构，得从内存布局下手**。

现象不是“报错”，而是吞吐量卡在某个值、增加线程数后延迟反而飙升、CPU 利用率高但有效计算少。这时候要怀疑伪共享，而不是立刻改算法。

用 perf stat -e cache-misses,instructions,cpu-cycles 跑 Java 进程（需 attach 或 fork），如果 cache-misses 占 instructions 比例 > 1%，尤其在高并发写场景下，基本坐实
JMH 是更准的手段：写两个 @Benchmark 方法，一个操作字段 a，一个操作字段 b，再写一个同时操作两者的版本；如果“分开跑快、一起跑慢”，且差值在 3 倍以上，大概率是伪共享
注意排除干扰：确保测试时没有 GC 压力（用 -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=10 等压稳），也不要用 System.out.println 打乱缓存行为

@Contended 是 JDK 提供的“自动填充”方案，但它不是开关一按就灵，必须配对 JVM 参数和正确路径。

JDK 8/9 必须加：-XX:+UnlockExperimentalVMOptions -XX:+UseContended；JDK 10+ 只需 -XX:+UnlockExperimentalVMOptions（-XX:+UseContended 默认开启）
注解路径不能混：JDK 8 用 @sun.misc.Contended，JDK 9+ 必须用 @jdk.internal.vm.annotation.Contended；混用编译不报错，但运行时完全无效
动态生成类（如 ByteBuddy、CGLIB 增强的类）中，@Contended 会被丢弃——因为字节码生成器通常不复制注解信息；此时只能退回到手动填充
填充宽度可调：-XX:ContendedPaddingWidth=128，但该值必须是 2 的幂，且不能小于当前 CPU 缓存行大小（x86 下通常是 64）

目标是让两个关键字段之间至少隔开 64 字节，所以填充字节数 = 64 − 字段自身大小。对 long 或 volatile long 来说，就是 64 − 8 = 56 字节。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

填 7 个 long 字段（7 × 8 = 56 字节）最稳妥，不要用 int 或 byte 拼凑，避免因 JVM 字段重排序或对齐规则导致实际间隔不足
字段名必须声明为 private 且无访问器，否则 JIT 可能优化掉（虽然概率低，但生产环境别赌）
别在同一个类里填完又放第三个热点字段——比如 a + 填充 + b + 填充 + c，c 仍可能和 a 落在同一缓存行；应把每个热点字段隔离到独立类中（如 Disruptor 的 RingBuffer 把 cursor 和 sequence 放不同对象）

很多人给 head 和 tail 中间塞 56 字节，结果发现性能提升有限——因为 JVM 对象头（12 字节）、字段对齐（8 字节边界）、以及数组元素连续性，会让填充失效。

Disruptor 的真实做法是：把 head 放进 Sequencer 类，tail 放进 RingBuffer 类，两者不共享任何对象实例；甚至进一步把每个消费者自己的 sequence 拆成独立对象，彻底切断缓存行耦合
如果你用的是 AtomicLong，别继承它再加 padding；而是封装：定义 class PaddedSequence { @Contended volatile long value; }，然后每个线程持有一个独立实例
数组场景更危险：long[] counters = new long[8]，哪怕只用 counters[0] 和 counters[1]，它们也必然落在同一缓存行（相邻 8 字节）；此时应改用对象数组 PaddedCounter[]，每个元素是独立填充对象