Java 伪共享问题的稳定解法

背景

用户咨询了一个java中cpu缓存伪共享场景，他通过padding多个long 字段隔离 2 个volatile字段，但是实测效果没有提升。
这是个比较有趣的场景，在 jdk8 有更稳定的方案去解决伪共享带来的性能问题。
下面我们展开介绍

伪共享问题是什么
用户padding方案为何失效
jdk 的新解法、实现方式和最佳实践

伪共享问题

伪共享（False Sharing）就是多个线程修改位于同一缓存行内的不同变量，导致缓存频繁失效，拖累系统性能。
举个例子：
当两个不相关的变量 A 和 B 恰好落在同一个缓存行时，如果 CPU 核心 1 修改了 A，会导致 CPU 核心 2 的缓存行失效。即使核心 2 只是在操作 B，也必须重新从内存加载数据，这会产生巨大的性能损耗。

引发上面现象的原因是Cache Line，CPU 读取内存时，不是按字节读的，一般是以 64 字节为单位读入缓存，变量地址很近，会在同一个Cache Line里，哪怕后面的变量不会被当前代码执行，也会被加载。Cache Line大小不同环境会有差异，我们可以用如下命令来确认。

cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size

这里只做简述，网上有更详细的图解。

在了解cpu伪共享形成的原因后，解决方法也就很多了。
4. 对象不变，减少不必要的并发。
5. 增加冲突对象的地址距离。

2 的修改比 1 简单，也是最常见的解法，上述用户的修改也是 2 的方式。

用户padding方案失效原因

我把用户的代码做了精简。

public class DataSharingTest {
   public volatile int m;
   public volatile long valueA = 0L;
   public long p1, p2, p3, p4, p5, p6, p7;
   public volatile long valueB = 0L;
   public volatile int j;
}

有并发冲突的是开头的 m 和结尾的 j。他中间加了 long，一个 long 在 java里是 8 字节。中间这么多 long 类型，长度已经超过了 64 字节。
这种写法用户是参考了同事的，并且在他同事那边验证是有效的。

从跑的实际结果上看对象的内存地址是没有分开的。这里被 java 的2 个特性给误导了。
写过c++的同学都经历过计算对象大小的时期，相同的成员变量存在长度不同时，不同的顺序会导致整体对象大小有差异。java 似乎没有要求成员变量顺序，是因为 java自己做了字段重排序，重排成一个最省内存的版本。这就导致了代码的编写和实际运行产生的差异。

我们打出内存对象结构。

com.contended.DataSharingTest object internals:
OFF  SZ   TYPE DESCRIPTION               VALUE
 0   8        (object header: mark)     N/A
 8   8        (object header: class)    N/A
16   8   long DataSharingTest.valueA    N/A
24   8   long DataSharingTest.p1        N/A
32   8   long DataSharingTest.p2        N/A
40   8   long DataSharingTest.p3        N/A
48   8   long DataSharingTest.p4        N/A
56   8   long DataSharingTest.p5        N/A
64   8   long DataSharingTest.p6        N/A
72   8   long DataSharingTest.p7        N/A
80   8   long DataSharingTest.valueB    N/A
88   4    int DataSharingTest.m         N/A
92   4    int DataSharingTest.j         N/A
Instance size: 96 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total

可以看到 m 和 j 还是排在一起的。类似的代码为什么他同事的是有效的呢，主要来自另外一个特性，指针压缩。

上面object header: class指针压缩时大小只有 4。

com.contended.DataSharingTest object internals:
OFF  SZ   TYPE DESCRIPTION               VALUE
 0   8        (object header: mark)     N/A
 8   4        (object header: class)    N/A
12   4    int DataSharingTest.m         N/A
16   8   long DataSharingTest.valueA    N/A
24   8   long DataSharingTest.p1        N/A
32   8   long DataSharingTest.p2        N/A
40   8   long DataSharingTest.p3        N/A
48   8   long DataSharingTest.p4        N/A
56   8   long DataSharingTest.p5        N/A
64   8   long DataSharingTest.p6        N/A
72   8   long DataSharingTest.p7        N/A
80   8   long DataSharingTest.valueB    N/A
88   4    int DataSharingTest.j         N/A
92   4        (object alignment gap)    
Instance size: 96 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

这里他同事的最终结果。m 和 j 在内存地址上就是分开的。

java 是同时包含了编译、解释、jit 的语言。使用手动增加变量的方式，弄不好哪个特性或者优化就会导致失效。

jdk的特性和实践

jdk 本身也要编写高并发的库，他也会遇到伪共享问题，在 jdk8中提供了一种稳定的方式来增加内存地址距离。这就是@Contended注解。

jvm虚拟机支持注解

jvm 虚拟机在遇到@Contended注解时会自动增加空白的内存块。

void FieldLayoutBuilder::compute_regular_layout() {
 bool need_tail_padding = false;
 prologue();
 regular_field_sorting();

 if (_is_contended) {
   _layout->set_start(_layout->last_block());
   insert_contended_padding(_layout->start());
   need_tail_padding = true;
 }
...  
   if (!_contended_groups.is_empty()) {
   for (int i = 0; i < _contended_groups.length(); i++) {
     FieldGroup* cg = _contended_groups.at(i);
     LayoutRawBlock* start = _layout->last_block();
     insert_contended_padding(start);
     _layout->add(cg->primitive_fields(), start);
     _layout->add(cg->oop_fields(), start);
     need_tail_padding = true;
   }
 }
 }

insert_contended_padding就是在加入空白块。

void FieldLayoutBuilder::insert_contended_padding(LayoutRawBlock* slot) {
 if (ContendedPaddingWidth > 0) {
   LayoutRawBlock* padding = new LayoutRawBlock(LayoutRawBlock::PADDING, ContendedPaddingWidth);
   _layout->insert(slot, padding);
 }
}

ContendedPaddingWidth就是块的大小。默认为 128。

  product(int, ContendedPaddingWidth, 128,                                  \
         "How many bytes to pad the fields/classes marked @Contended with")\
         range(0, 8192)                                                    \
         constraint(ContendedPaddingWidthConstraintFunc,AfterErgo)

@Contended注解用法

@Contended算是有 3 种用法。
第一种就是加在字段上。

public class Monitoring {
   @Contended
   long readCount;
   @Contended
   long writeCount;

   long otherData; 
}

对象内存布局变化如下

OFF  SZ   TYPE DESCRIPTION               VALUE
 0   8        (object header: mark)     N/A
 8   4        (object header: class)    N/A
12   4        (alignment/padding gap)   
16   8   long Monitoring1.otherData     N/A
24 128        (alignment/padding gap)   
152   8   long Monitoring1.readCount     N/A
160 128        (alignment/padding gap)   
288   8   long Monitoring1.writeCount    N/A
296 128        (object alignment gap)    
Instance size: 424 bytes
Space losses: 260 bytes internal + 128 bytes external = 388 bytes total

加了注解的字段前会加入 128 的内存块。
第二种就是组管理

public class Monitoring {
   @Contended("stats")
   long readCount;
   @Contended("stats")
   long writeCount;
   
   long otherData; // 不在组内
}

注解内可以加组名，这样相同组名的变量会放在一起。

OFF  SZ   TYPE DESCRIPTION               VALUE
 0   8        (object header: mark)     N/A
 8   4        (object header: class)    N/A
12   4        (alignment/padding gap)   
16   8   long Monitoring.otherData      N/A
24 128        (alignment/padding gap)   
152   8   long Monitoring.readCount      N/A
160   8   long Monitoring.writeCount     N/A
168 128        (object alignment gap)    
Instance size: 296 bytes
Space losses: 132 bytes internal + 128 bytes external = 260 bytes total

这种更利于，每次改动都是多个变量的场景。

第三种是加在类上。

@Contended
public class Monitoring2 {
   long readCount;
   long writeCount;
}

这种是作用在每个对象上。适合有对象数组的场景，数组的对象在内存上都是相邻的，通过增加对象的大小，可以保证操作对象之间不会产生影响。

OFF  SZ   TYPE DESCRIPTION               VALUE
 0   8        (object header: mark)     N/A
 8   4        (object header: class)    N/A
12 132        (alignment/padding gap)   
144   8   long Monitoring2.readCount     N/A
152   8   long Monitoring2.writeCount    N/A
Instance size: 160 bytes
Space losses: 132 bytes internal + 0 bytes external = 132 bytes total

jdk里的应用

这里展示一下 jdk 代码里的应用场景
java.lang.Thread把随机种子相关的都放在一个组里，避免了和其他字段的共享。

    /** The current seed for a ThreadLocalRandom */
   @jdk.internal.vm.annotation.Contended("tlr")
   long threadLocalRandomSeed;

   /** Probe hash value; nonzero if threadLocalRandomSeed initialized */
   @jdk.internal.vm.annotation.Contended("tlr")
   int threadLocalRandomProbe;

   /** Secondary seed isolated from public ThreadLocalRandom sequence */
   @jdk.internal.vm.annotation.Contended("tlr")
   int threadLocalRandomSecondarySeed;

java.util.concurrent.Exchanger把 Slot类增加注解，内部是一个Slot[]维护，避免互相干扰。

 /**
    * Padded arena cells to avoid false-sharing memory contention
    */
   @jdk.internal.vm.annotation.Contended
   static final class Slot {
       Node entry;
   }

   
   /**
    * Elimination array; element accesses use emulation of volatile
    * gets and CAS.
    */
   private final Slot[] arena;

最佳实践

上面可以看到jdk.internal.vm.annotation.Contended，这是一个 jdk 内部注解。我们如果引入需要增加

--add-exports=java.base/jdk.internal.vm.annotation=ALL-UNNAMED

保证编译和运行通过。jdk 默认是不对用户的模块生效的，我们使用时需要关闭RestrictContended。

 -XX:-RestrictContended

这种解法本质就是一种拿内存换性能。带来的内存损耗需要仔细评估，否则会带来GC和 OOME。解决的方法有了，我们如何找到比较重要的代码增加注解呢，这里就用到了底层能力。
最直接的发现是 c2c

perf c2c record

不过这里需要有内存的事件，不一定有权限。我们可以通过L1-dcache-load-misses来侧面反映。

perf -e L1-dcache-load-misses

背景

伪共享问题

用户padding方案失效原因

jdk的特性和实践

jvm虚拟机支持注解

@Contended注解用法

jdk里的应用

最佳实践

相关文章

都叫“分代”，ZGC 和 G1 根本不是一回事：实测停顿差 1300 倍

慢半拍的 Flink TaskManager：问题不在代码里

JFR 转火焰图工具