伪共享是多线程在不同cpu核心修改同一64字节缓存行内无关变量，触发mesi协议频繁同步，导致cache-misses升高、吞吐量下降；解决需物理隔离字段，如用@contended注解或手动填充确保64字节对齐。
伪共享不是代码写错了，而是多个线程在不同 CPU 核心上修改同一缓存行里的不同变量，导致缓存频繁失效、同步开销陡增。它不报错，但会让高并发吞吐量卡在瓶颈——加核反而变慢、CPU 使用率高、cache-misses 显著上升。
为什么会出现伪共享
CPU 不按字节读内存，而是以缓存行为单位（主流是 64 字节）加载数据。一个缓存行可能包含 8 个 long 字段（每个 8 字节）。当线程 A 修改字段 X，整个缓存行被标记为 dirty；线程 B 即使只读或写同一行里的字段 Y，也会因该行副本失效而被迫重新加载整行——哪怕 X 和 Y 完全无关。
这种“误伤式同步”由 MESI 等缓存一致性协议触发，本质是硬件级副作用，和锁、volatile 语义无关。
- 典型场景：LongAdder 的 Cell 数组中相邻 Cell 的 value 字段挤在同一缓存行
- 典型表现：多线程计数器性能随核心数增加不升反降，perf stat 显示 cache-misses >1%
- 关键点：伪共享只发生在不同核心修改同一缓存行内不同字段时；同核线程不触发
怎么让敏感字段物理隔离
核心思路是确保高频更新的字段之间至少间隔 64 字节，使其无法落入同一缓存行。有两类常用方式：
- 手动填充：在字段前后插入无用 long 字段（如 p1–p7），凑够约 56 字节填充 + 字段自身 8 字节 = 64 字节对齐
- @Contended 注解：JVM 在对象布局阶段自动插入填充字节，默认预留约 128 字节（前后各 ~64 字节），更可靠且免于手算
注意：手动填充可能被 JVM 优化掉（如字段重排或消除），@Contended 则由 JVM 层面强制保障布局，稳定性更高。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
@Contended 的正确用法与限制
这个注解不是加了就生效，必须满足几个硬性条件：
- 启用实验选项：
-XX:+UnlockExperimentalVMOptions -XX:-RestrictContended - 使用 JDK 内置注解：
jdk.internal.vm.annotation.Contended（JDK 9+）或@sun.misc.Contended（JDK 8） - 仅对实例字段有效；static 字段、java.* 等 bootstrap classloader 加载的类不支持
- 可选调优：用
-XX:ContendedPaddingWidth=64控制填充宽度
例如，在 LongAdder 的 Cell 类中给 value 字段加注解，就能避免多个 Cell 的 value 被挤进同一缓存行。
效果与代价要心里有数
@Contended 的收益体现在底层指标变化：
- L1 数据缓存 miss 明显下降
- CAS 失败率降低（不再因无关字段更新而失效本地缓存）
- 多核扩展性改善：QPS 随核心数增长趋于线性
代价是内存占用上升，单个 @Contended 字段通常多占 128~256 字节。适合高频更新、竞争激烈的字段，不建议滥用在普通 POJO 上。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
