浅谈“伪共享”问题
前言
学习的过程中遇到了一个名词——伪共享，出于对知识的兴趣，上网查阅了一些博文，研究了伪共享的问题，写此文章总结记录。
要很好的理解伪共享问题，我们要先从CPU的缓存开始说起。
CPU缓存架构
CPU 是计算机的心脏，所有运算和程序最终都要由它来执行。
主内存（RAM）是数据存放的地方，CPU 和主内存之间有好几级缓存，因为即使直接访问主内存也是非常慢的。
如果对一块数据做相同的运算多次，那么在执行运算的时候把它加载到离 CPU 很近的地方就有意义了，比如一个循环计数，你不想每次循环都跑到主内存去取这个数据来增长它吧。
再对缓存的概念做一些说明：
越靠近 CPU 的缓存越快也越小。
所以 L1 缓存很小但很快，并且紧靠着在使用它的 CPU 内核。
L2 大一些，也慢一些，并且仍然只能被一个单独的 CPU 核使用。
L3 在现代多核机器中更普遍，仍然更大，更慢，并且被单个插槽上的所有 CPU 核共享。
最后，主存保存着程序运行的所有数据，它更大，更慢，由全部插槽上的所有 CPU 核共享。
当 CPU 执行运算的时候，它先去 L1 查找所需的数据，再去 L2，然后是 L3，最后如果这些缓存中都没有，所需的数据就要去主内存拿。
走得越远，运算耗费的时间就越长。
所以如果进行一些很频繁的运算，要确保数据在 L1 缓存中。
CPU缓存行
缓存是由缓存行组成的，通常是 64 字节（常用处理器的缓存行是 64 字节的，比较旧的处理器缓存行是 32 字节），并且它有效地引用主内存中的一块地址。
一个 Java 的 long 类型是 8 字节，因此在一个缓存行中可以存 8 个 long 类型的变量。
在程序运行的过程中，缓存每次更新都从主内存中加载连续的 64 个字节。因此，如果访问一个 long 类型的数组时，当数组中的一个值被加载到缓存中时，另外 7 个元素也会被加载到缓存中。
但是，如果使用的数据结构中的项在内存中不是彼此相邻的，比如链表，那么将得不到免费缓存加载带来的好处。
不过，这种免费加载也有一个坏处。设想如果我们有个 long 类型的变量 a，它不是数组的一部分，而是一个单独的变量，并且还有另外一个 long 类型的变量 b 紧挨着它，那么当加载 a 的时候将免费加载 b。
看起来似乎没有什么毛病，但是如果一个 CPU 核心的线程在对 a 进行修改，另一个 CPU 核心的线程却在对 b 进行读取。
当前者修改 a 时，会把 a 和 b 同时加载到前者核心的缓存行中，更新完 a 后其它所有包含 a 的缓存行都将失效，因为其它缓存中的 a 不是最新值了。
而当后者读取 b 时，发现这个缓存行已经失效了，需要从主内存中重新加载。
请记住，我们的缓存都是以缓存行作为一个单位来处理的，所以失效 a 的缓存的同时，也会把 b 失效，反之亦然。
这样就出现了一个问题，b 和 a 完全不相干，每次却要因为 a 的更新需要从主内存重新读取，它被缓存未命中给拖慢了。
这就是传说中的伪共享。
何为伪共享（False Sharing）
从上面我们的原理讲解中，对伪共享有了理性的认识。
这里我们先给伪共享下个定义：
当多线程修改互相独立的变量时，如果这些变量共享同一个缓存行，就会无意中影响彼此的性能，这就是伪共享。
我们从一个例子来看”伪共享”产生的作用：
public class FalseSharingTest {
public static void main(String[] args) throws InterruptedException {
testPointer(new Pointer());
}
private static void testPointer(Pointer pointer) throws InterruptedException {
long start = System.currentTimeMillis();
Thread t1 = new Thread(() -> {
for (int i = 0; i < 100000000; i++) {
pointer.x++;
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 100000000; i++) {
pointer.y++;
}
});
tstart();
tstart();
tjoin();
tjoin();
System.out.println(System.currentTimeMillis() - start);
System.out.println("x: "+pointer.x);
System.out.println("y: "+pointer.y);
}
}
class Pointer {
volatile long x;
volatile long y;
}我们声明了一个 Pointer 的类，它包含 x 和 y 两个变量（必须声明为volatile，保证可见性），一个线程对 x 进行自增1亿次，一个线程对 y 进行自增1亿次。
可以看到，x 和 y 完全没有任何关系，但是更新 x 的时候会把其它包含 x 的缓存行失效，同时也就失效了 y，运行这段程序输出的时间为 3458ms。
运行结果：
3458
x: 100000000
y: 100000000运行了多次，结果都是在3000ms左右。
虽然从这个时间上我们好像看不出来有什么伪共享的问题，无非可能有点慢而已，但我们没有别的证据。别急，我们下面会有答案的。
避免伪共享
伪共享的原理我们知道了，一个缓存行是 64 个字节，一个 long 类型是 8 个字节，所以避免伪共享也很简单，大概有以下三种方式。
方法一 填充(Padding)
顾名思义，填充的思想就是在两个变量之间填充到64个字节，把第二个变量挤到下一个缓存行。
我们的例子中在两个 long 类型的变量之间再加 7 个 long 类型，把Pointer改成下面的结构之后：
class Pointer {
volatile long x;
long p1, p2, p3, p4, p5, p6, p7;
volatile long y;
}发现时间神奇的缩短了4分之一，多次试验，大概都在800ms左右：
720
x: 100000000
y: 100000000这个结果也充分证明了伪共享的存在。
注意：在考虑使用填充之前，必须要了解的一点是JVM可能会清除无用字段或重排无用字段的位置，这样的话，可能无形中又会引入伪共享。我们也没有办法指定对象在堆内驻留的位置。
方法二 自己创建对象
我们尝试使用另外一种方式，我们重新创建自己的long类型，而不是Java自带的long：
class Pointer {
MyLong x=new MyLong();
MyLong y=new MyLong();
}
class MyLong{
volatile long value;
}同时把 pointer.x++; 修改为 pointer.x.value++;，把 pointer.y++; 修改为 pointer.y.value++;，再次运行程序发现时间是 752ms。
可以看到也解决了伪共享问题。
方法三 使用 @sun.misc.Contended 注解（java8）
除了对字段进行填充之外，还有一个比较清爽的方法，那就是对需要避免陷入伪共享的字段进行注解，这个注解暗示JVM应当将字段放入不同的缓存行。
如下添加@Contended注解：
import sun.misc.Contended;
class Pointer {
@Contended
volatile long x;
volatile long y;
}默认使用这个注解是无效的，需要在JVM启动参数加上 -XX:-RestrictContended才会生效：
再次运行程序发现时间是 749ms：
749
x: 100000000
y: 100000000说明：引入了@Contented注解，被这个注解修饰的字段应当和其他的字段驻留在不同的位置。上面的代码将x和y置于不同的缓存行。@Contented注解将y移动到远离对象头部的地方，(以避免和x一起被加载到同一个缓存行)。
参考资料
杂谈 什么是伪共享（false sharing）？ （注：这篇文章中的避免伪共享的方案中的代码及解释有误，本文已纠正）
Java8中@Contended和伪共享
总结
（1）CPU具有多级缓存，越接近CPU的缓存越小也越快；
（2）CPU缓存中的数据是以缓存行为单位处理的；
（3）CPU缓存行能带来免费加载数据的好处，所以处理数组性能非常高；
（4）CPU缓存行也带来了弊端，多线程处理不相干的变量时会相互影响，也就是伪共享；
（5）避免伪共享的主要思路就是让不相干的变量不要出现在同一个缓存行中，常见的有填充、创建自己的变量、使用注解三种方式避免伪共享。