而在 JDK 8 里面 AtomicLong 里面的一些方法也是自旋，但是就不仅仅依赖于
cmpxchg 指令做了，比如还是上面这个方法：
可以看到这里面还是有一个 do-while 的循环，还是调用的 compareAndSwapLong 方法：
这个方法对应的 Lock 前缀指令是我们前面提到过的 xadd 指令。
从 Java 代码的角度来看，都是自旋，都是 compareAndSwapLong 方法。没有什么差异。
但是从这篇 oracle 官网的文章，我们可以窥见 JDK 8 在 x86 平台上对 compareAndSwapLong 方法做了一些操作，使用了 xadd 汇编指令代替 CAS 操作。
xadd 指令是 fetch and add。
cmpxchg 指令是 compare and swap。
xadd 指令的性能是优于 cmpxchg 指令的。
具体可以看看这篇 oracle 官网的文章：
https://blogs.oracle.com/dave/atomic-fetch-and-add-vs-compare-and-swap
文章下面的评论，可以多注意一下，我截取其中两个，大家品一品：
然后是这个：
总之就是：这篇文章说的有道理，我们（Dave and Doug）也在思考这个问题。所以我们会在 JIT 上面搞事情，在 x86 平台上把 CAS 操作替换为 LOCK:XADD 指令。
（这个地方我之前理解的有问题，经过朋友的指正后才修改过来。）
所以，JDK 8 之后的 AtomicLong 里面的方法都是经过改良后， xadd+cmpxchg 双重加持的方法。
另外需要注意的是，我怕有的朋友懵逼，专门多提一嘴：CAS 是指一次比较并交换的过程，成功了就返回 true，失败了则返回 false，强调的是一次。而自旋 CAS 是在死循环里面进行比较并交换，只要不返回 true 就一直循环。
所以，不要一提到 CAS 就说循环时间开销大。前面记得加上“自旋”和“竞争大”两个条件。
至于 JDK 8 使用 xadd 汇编指令代替 CAS 操作的是否真的是性能更好了，可以看看这篇 oracle 官网的文章：
https://blogs.oracle.com/dave/atomic-fetch-and-add-vs-compare-and-swap
文章下面的评论，可以多注意一下，我截取其中一个，大家品一品：
经过我们前面的分析，AtomicLong 从 JDK 7 到 JDK 8 是有一定程度上的性能优化的，但是改动并不大。
还是存在一个问题：虽然它可以实现原子性的增减操作，但是当竞争非常大的时候，被操作的这个 value 就是一个热点数据，所有线程都要去对其进行争抢，导致并发修改时冲突很大。
所以，归根到底它的主要问题还是出在共享热点数据上。
为了解决这个问题，Doug Lea 在 JDK 8 里面引入了 LongAdder 类。
更加牛逼的LongAdder
大家先看一下官网上的介绍：
上面的截图一共两段话，是对 LongAdder 的简介，我给大家翻译并解读一下。
首先第一段：当有多线程竞争的情况下，有个叫做变量集合（set of variables）的东西会动态的增加，以减少竞争。sum() 方法返回的是某个时刻的这些变量的总和。
所以，我们知道了它的返回值，不论是 sum() 方法还是 longValue() 方法，都是那个时刻的，不是一个准确的值。
意思就是你拿到这个值的那一刻，这个值其实已经变了。
这点是非常重要的，为什么会是这样呢？
我们对比一下 AtomicLong 和 LongAdder 的自增方法就可以知道了：
AtomicLong 的自增是有返回值的，就是一个这次调用之后的准确的值，这是一个原子性的操作。
LongAdder 的自增是没有返回值的，你要获取当前值的时候，只能调用 sum 方法。
你想这个操作：先自增，再获取值，这就不是原子操作了。
所以，当多线程并发调用的时候，sum 方法返回的值必定不是一个准确的值。除非你加锁。
该方法上的说明也是这样的：
至于为什么不能返回一个准确的值，这就是和它的设计相关了，这点放在后面去说。
然后第二段：当在多线程的情况下对一个共享数据进行更新（写）操作，比如实现一些统计信息类的需求，LongAdder 的表现比它的老大哥 AtomicLong 表现的更好。在并发不高的时候，两个类都差不多。但是高并发时 ngAdder 的吞吐量明显高一点，它也占用更多的空间。这是一种空间换时间的思想。
这段话其实是接着第一段话在进行描述的。
因为它在多线程并发情况下，没有一个准确的返回值，所以当你需要根据返回值去搞事情的时候，你就要仔细思考思考，这个返回值你是要精准的，还是大概的统计类的数据就行。
比如说，如果你是用来做序号生成器，所以你需要一个准确的返回值，那么还是用 AtomicLong 更加合适。
如果你是用来做计数器，这种写多读少的场景。比如接口访问次数的统计类需求，不需要时时刻刻的返回一个准确的值，那就上 LongAdder 吧。
总之，AtomicLong 是可以保证每次都有准确值，而 LongAdder 是可以保证最终数据是准确的。高并发的场景下 LongAdder 的写性能比 AtomicLong 高。
接下来探讨三个问题：
- LongAdder 是怎么解决多线程操作热点 value 导致并发修改冲突很大这个问题的？
- 为什么高并发场景下 LongAdder 的 sum 方法不能返回一个准确的值？
- 为什么高并发场景下 LongAdder 的写性能比 AtomicLong 高？
先带大家看个图片，看不懂没有关系，先有个大概的印象：
接下来我们就去探索源码，源码之下无秘密。
从源码我们可以看到 add 方法是关键：
里面有 cells 、base 这样的变量，所以在解释 add 方法之前，我们先看一下 这几个成员变量。
这几个变量是 Striped64 里面的。
LongAdder 是 Striped64 的子类：
其中的四个变量如下：
- NCPU：cpu 的个数，用来决定 cells 数组的大小。
- cells：一个数组，当不为 null 的时候大小是 2 的次幂。里面放的是 cell 对象。
- base : 基数值，当没有竞争的时候直接把值累加到 base 里面。还有一个作用就是在 cells 初始化时，由于 cells 只能初始化一次，所以其他竞争初始化操作失败线程会把值累加到 base 里面。
- cellsBusy：当 cells 在扩容或者初始化的时候的锁标识。
之前，文档里面说的 set of variables 就是这里的 cells。
