避免伪共享需让高频修改变量独占64字节缓存行，核心方案包括：①用填充字段隔离（如7个long）；②jdk8+用@contended注解并启用-xx:-restrictcontended；③重构设计，如threadlocal、longadder或索引间隔布局。

避免Java多线程下因操作基本类型变量引发的伪共享，核心是让高频修改的变量独占缓存行（通常64字节），切断不必要的缓存同步链路。这不是靠加锁或改逻辑能解决的，而是要从内存布局入手。

理解伪共享发生的物理前提

CPU以缓存行为单位加载和写回数据，主流大小为64字节。如果两个volatile long字段（各占8字节）在对象中紧挨着定义，它们大概率落在同一缓存行里。线程A改第一个，线程B改第二个，硬件层面会反复使对方缓存行失效——即使代码里完全没共享逻辑。

• 对象头一般占12字节（开启压缩指针时），之后字段按声明顺序紧凑排列
• long/double对齐到8字节边界，int/short等按自身大小对齐
• 数组元素天然连续，相邻索引极易落入同一缓存行

用填充字段隔离关键变量（JDK 8之前通用方案）

在目标变量前后插入无意义的long字段，把总占用撑满64字节。例如：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

static final class PaddedCounter {
    public volatile long value = 0L;
    // 填充56字节：7个long × 8字节
    public long p1, p2, p3, p4, p5, p6, p7;
}

• value + 7个填充字段 = 8 × 8 = 64字节，刚好填满一行
• 若变量类型是int，需按8字节对齐计算实际填充量（比如补6个long+1个int可能更准）
• 注意：填充字段必须是实例变量，静态字段无效；字段名不重要，但不能被JVM优化掉（所以不用final）

用@Contended注解自动处理（JDK 8+推荐）

这是更简洁、更可靠的方案，但需配合JVM参数启用：

@sun.misc.Contended
static final class ContendedCounter {
    public volatile long value = 0L;
}

• 启动时必须加参数：-XX:-RestrictContended
• 可选配置填充宽度：-XX:ContendedPaddingWidth=64（默认就是64）
• @Contended作用于类、字段或内部类，标注后JVM会在其前后插入填充区
• 注意：该注解在JDK9+被标记为deprecated，但目前仍是官方支持的解决方案

调整数据结构设计，从源头规避

比硬编码填充更优雅的方式是重构访问模式：

• 把每个线程专属的计数器放在独立对象里，而非共用一个对象的多个字段
• 使用ThreadLocal存储线程私有变量，彻底避开跨核缓存交互
• 数组场景下，让线程操作间隔足够远的索引（如stride ≥ 64 / 元素大小），或用一维转二维索引分散布局
• 优先选用java.util.concurrent.atomic包中已做缓存对齐的类，如LongAdder内部就用了Cell数组+填充

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南