写Java也得了解CPU--伪共享

第一次接触伪共享的概念,是在马丁的博客上;而ifeve也把这一系列博文翻译整理好了。概读了几次,感觉到此概念的重要。因此有了这个系列的第二篇读后总结。

 

1. 什么是伪共享(False sharing)

上一篇博文知道,缓存的存储方式,是以缓存行(Cache Line)为单位的。一般缓存行的大小是64字节。这意味着,小于64字节的变量,是有可能存在于同一条缓存行的。例如变量X大小32字节,变量Y大小32字节,那么他们有可能会存在于一条缓存行上。

根据马丁博客上的定义,伪共享,就是多个线程同时修改共享在同一个缓存行里的独立变量,无意中影响了性能

 

2.伪共享是怎么发生的

借助马丁的图,我们可以窥知伪共享发生的过程。

 

 

当核心1上的线程想更新X,而核心2上的线程想更新Y,而X变量和Y变量在同一个缓存行中时;每个线程都要去竞争缓存行的所有权来更新变量。如果核心1获得所缓存行的所有权,那么缓存子系统将会使核心2中对应的缓存行失效,反之亦然。这会来来回回的经过L3缓存,大大影响了性能。这种情况,就像多个线程同事竞争锁的所有权一样。如果互相竞争的核心位于不同的插槽,就要额外横跨插槽连接,问题可能更加严重。

 

3. 怎么发现伪共享

很遗憾,没有特别直接有效的方法。马丁自己也承认,伪共享相当难发现,因此有“无声性能杀手”之称。但这不意味着无法发现。通过观察L2和L3的缓存命中和丢失的情况,可以从侧面发现是否有伪共享的发生。

 

4. 怎么解决伪共享

对于伪共享这种影响性能的问题,解决是关键。解决伪共享的方法是通过补齐(Padding),使得每一条缓存行只存一个多线程变量。请看下面的代码:

public final class FalseSharing implements Runnable {
    public final static int NUM_THREADS = 2; // change
    public final static long ITERATIONS = 500L * 1000L * 1000L;
    private final int arrayIndex;

    private static VolatileLong[] longs = new VolatileLong[NUM_THREADS];
    static {
        for (int i = 0; i < longs.length; i++) {
            longs[i] = new VolatileLong();
        }
    }

    public FalseSharing(final int arrayIndex) {
        this.arrayIndex = arrayIndex;
    }

    public static void main(final String[] args) throws Exception {
        
        //test the size of VolatileLong
        System.out.println(ClassLayout.parseClass(VolatileLong.class).toPrintable());

        final long start = System.nanoTime();
        runTest();
        System.out.println("duration = " + (System.nanoTime() - start));
    }

    private static void runTest() throws InterruptedException {
        Thread[] threads = new Thread[NUM_THREADS];

        for (int i = 0; i < threads.length; i++) {
            threads[i] = new Thread(new FalseSharing(i));
        }

        for (Thread t : threads) {
            t.start();
        }

        for (Thread t : threads) {
            t.join();
        }
    }

    public void run() {
        long i = ITERATIONS + 1;
        while (0 != --i) {
            longs[arrayIndex].value = i;
        }
    }

    public final static class VolatileLong {
        public volatile long value = 0L;
        public long p1, p2, p3, p4, p5, p6; // comment out in order to trigger false sharing
    }
    

}

 

改变线程的数量以及运行此程序(基于Intel Xeon E31270 8GB/64bit Win7/64bit jdk 6),会得到以下的结果:

这个结果没有马丁的结果那么惊人,伪共享在3-4线程的时候会比较明显地影响性能。这个结果后面还会继续分析。然而这并不是个完美的测试,因为我们不能确定这些VolatileLong会布局在内存的什么位置。它们是独立的对象。但是经验告诉我们同一时间分配的对象趋向集中于一块。

 

5.一些思考

上面是马丁对伪共享的初步解释。说实话,解释得略微简略了一点。读了几次,还是有不太明白的地方,因此厚着脸皮在这里发了个帖子问点疑惑,结果得到马丁本人,Nitsan和Peter等众大神的回答,收益匪浅。下面摘录点我的疑惑和他们的解答,更好的理解伪共享:

 

5.1 上文得知,L1缓存和L2缓存是核心私有的缓存,不同的核心并不共享L1和L2缓存。为什么核心1更新它自己L1上的X,而核心2更新它自己L1上的Y,会发生伪共享?

要回答这个问题,首先得稍微了解CPU缓存工作的协议,MESI。这套协议是用来保证CPU缓存的一致性的(cache coherency)。简单来说,这协议定义了多级缓存下的同一个变量改变后,该怎么办。这套协议相当复杂,这里只是介绍伪共享相关的知识点,来回答我们的问题。

我们知道,缓存的最小使用单位,是缓存行。如上面所假设,变量X和变量Y不幸在同一个缓存行里,而核心1需要X,核心2需要Y。这时候,核心1就会拷贝这条缓存行到自己的L1,核心2也一样。所以这条缓存行在L3,核心1的L1和核心2的L1里,正如上图所示。

假设核心1修改变量X,那么根据MESI协议,这个缓存行的状态就会变成M(Modified),表面这一行数据和内存数据不一致,得回写(write back)此缓存行到L3里。而这时,需要发送一个Request For Ownership (RFO),来获得L3的这条缓存行的所有权。由于X和Y在同一条缓存行,虽然核心2修改的变量是Y,但也需要做同样的事情-发送RFO获得L3同一条缓存行的所有权。因此,伪共享就这样在L3里发生了。

 

5.2 补齐(Padding)会不会有失效的时候?

会的。Java 7淘汰或是重新排列了无用的字段,因此上述的补齐在Java 7里已经失效了,伪共享还会发生。要避免伪共享,需要改变补齐的方式如下:

 public static long sumPaddingToPreventOptimisation(final int index)
    {
        PaddedAtomicLong v = longs[index];
        return v.p1 + v.p2 + v.p3 + v.p4 + v.p5 + v.p6;
    }
 
    public static class PaddedAtomicLong extends AtomicLong
    {
        public volatile long p1, p2, p3, p4, p5, p6 = 7L;
    }

这个方法的由来在这里,并不打算深究。要注意的是,这个方法sumPaddingToPreventOptimisation只是用来防止JVM7消除无用的字段。

 

5.3 怎么计算VolatileLong的大小?为什么这样补齐可以使它符合缓存行64字节大小?

理论上,我们知道在64bit Hotspot JVM下,一个long占8字节之类的知识。但实际的对象占多少字节,怎么分布,得依靠这个工具--JOL来测量。下面是补齐前和补齐后,VolatileLong的输出:

VolatileLong object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 12 (object header) N/A
12 4 (alignment/padding gap) N/A
16 8 long VolatileLong.value N/A
Instance size: 24 bytes (estimated, the sample instance is not available)
Space losses: 4 bytes internal + 0 bytes external = 4 bytes total

VolatileLong object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 12 (object header) N/A
12 4 (alignment/padding gap) N/A
16 8 long VolatileLong.value N/A
24 8 long VolatileLong.p1 N/A
32 8 long VolatileLong.p2 N/A
40 8 long VolatileLong.p3 N/A
48 8 long VolatileLong.p4 N/A
56 8 long VolatileLong.p5 N/A
64 8 long VolatileLong.p6 N/A
Instance size: 72 bytes (estimated, the sample instance is not available)
Space losses: 4 bytes internal + 0 bytes external = 4 bytes total

这样,我们可以看到补齐前,VolatileLong只有24字节小于缓存行大小,补齐后就超过缓存行大小。

 

5.4 补齐的对象超过了缓存行,有没有影响会不会和接下来的变量发生潜在的伪共享?

假设补齐后,VolatileLong是72字节,紧接着刚好有一个变量Z是刚好56个字节,那么第二个缓存行存放着VolatileLong的8字节那一部分,以及变量Z。那么同时访问VolatileLong和Z,会不会发生伪共享呢?是不是一定要补齐到缓存行大小才完全避免伪共享呢?

答案是否定的,补齐超过缓存行,最多浪费点珍贵的缓存,但不会产生伪共享。请看下面的图:

| 8b | 16 | 24 | 32 | 40 | 48 | 56 | 64 |

| *  | *  | OH | OH | P   | P   | P   | P   |
| P  | P  | P    | V   | P   | P   | P   | P   |
| P  | P  | P    | *   | *   | *   | *   | *   |
 
如图所示,补齐的对象横跨3个缓存行时,我们需要的改变的变量,仅仅是V,只要保证V这个变量所在的同一条缓存行内,没有另外一个需要改变的变量,那么伪共享不会发生。
补充一句,Nitsan大神的补齐对象在这里。没细看,但估计补齐得更加完美。
 

5.5 为何上述测试8线程的结果回比4线程的结果要好?

这是因为,用来测试的机器的CPU只是4核心,伪共享的发生是在L3缓存。如果8线程的话,其实有线程是共享了L1缓存。
 

6. 最后

伪共享是实实在在的问题,而且相当隐蔽。但现在Java的多线程库,都会考虑到这个问题。例如Disruptor还有Netty都会使用Padding的类代替原有类,达到去除伪共享的目的。
 
 
参考:
 

本文完

 

posted @ 2014-03-27 14:27  macemers  阅读(3294)  评论(0编辑  收藏