在探讨 LongAdder 是如何解决伪共享问题之前，我们要先梳理清一个概念，什么是 伪共享 和 共享 ？
共享在 Java 编程里面我们可以这样理解，有一个 Share 类，它有一个 value 的属性。如下：
public class Share {
int value;
}复制代码
我们初始化 Share 的一个实例，然后启动多个线程去操作它的 value 属性，此时的 Share 变量被多个线程操作的这种情况我们称之为 共享。
大家都知道在不添加任何互斥措施的情况，多线程操作这个 Share 变量的 value 属性肯定存在线程安全性的问题。那有什么办法可以解决这个问题呢？我们可以使用 volatile 和 CAS 技术来保证共享变量可以安全的被多个线程共享操作使用，不知道 volatile 和 CAS 技术点的同学可以参考往期文章 ReentranLock 实现原理居然是这样？。
但是由于 volatile 的引入，会带来一些问题。大家都知道 JMM（Java 内存模型）规范了 volatile 具有内存可见性和禁止指令重排序的语义。这俩条语义使得某个线程更新本地缓存中的 value 值后会将其他线程的本地缓存中的value 值失效，然后其他线程再次读取 value 值的时候需要去主存里面获取 value 值，这样即保证了 value 的内存可见性。
当然啦，这没有任何问题，但是由于线程本地缓存的操作是以缓存行为单位的，一个缓存行大小通常为 64B（不同型号的电脑缓存行大小会有不同）。因此一个缓存行中不会只单单存储 value 一个变量，可能还会存储其他变量。这样当一个线程更新了 value 之后，如果其他线程本地缓存中同样缓存了 value， value 所在的缓存行就会失效，这意味着该缓存行上的其他变量也会失效，那么线程对这个该缓存行上所有变量的访问都需要从主存中获取。我们都知道 CPU 访问主存的速度相对于访问缓存的速度有着数量级的差距，这就带了很大的性能问题，我们将这个问题称之为 伪共享。
理解了伪共享到底是什么鬼以后，我们来看看 Java 大师们是怎么解决这个问题的。在早期版本的 JDK 里面你应该见到过类似如下的代码：
public class Share {
volatile int value;
long p1, p2, p3, p4, p5, p6;}复制代码
你可能猜到了，定义了几个无用的变量作为填充物，他们会保证一个缓存行里面只保存了 Share 变量，这样更新 Share 变量的时候就不会存在伪共享问题了。但是这种方法存在什么问题呢？
首先基于每台运行 Java 程序的机器的缓存行大小可能不同，其次由于这些类似填充物的变量并没有被实际使用，可以被 JVM 优化掉，这样就失效了。
基于此，在 Java 8 的时候，官方给出了手机号码拍卖解决策略，这就是 Contended 注解。依赖于这个注解，我们在 Java 8 环境下可以这样改善代码：
public class Share {
@Contended
volatile int value;
}复制代码
使用如上注解，并且在 JVM 启动参数中加入 -XX:-RestrictContended，这样 JVM 在运行时就会自动的为我们的 Share 类添加合适大小的填充物（padding）来解决伪共享问题，而不需要我们手写变量来作为填充物了，这样就更加便捷优雅的解决了伪共享问题。悄悄的告诉你，LongAdder 就是使用 Contended 来解决伪共享问题哒。
好了，相信你已经了解了什么是伪共享问题，以及早期并发编程大师是如何解决伪共享问题的，最后我们也介绍了在 Java 8 中使用 Contended 来更优雅的解决伪共享问题。Contended 还提供了一个缓存行分组的功能，在上文中我们没有介绍，欢迎有兴趣的小伙伴们自行探索吧。
