写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的类代替原有类，达到去除伪共享的目的。

 

 

参考：

http://coderplay.iteye.com/blog/1486649

 

本文完