前言
为了避免多线程下由于操作的原子性产生的安全问题，在JDK中的JUC包下提供了一系列使用非阻塞CAS算法实现的原子性操作类，相比使用锁实现的原子性减少了线程的上下文切换，在性能上有了很大的提高。
本文将总结一下JUC下面的一些典型类。
原子变量操作类
在JUC包下，有许多原子性操作类，如图：
里面有 AtomicInteger，AtomicLong，AtomicBoolean，AtomicLongArray等，因为原子性操作的实现逻辑类似，所以本文将总结逻辑相对简单的AtomicLong。
AtomicLong相关
AtomicLong是原子性递增或者递减类，内部使用了Unsafe来实现。
public class AtomicLong extends Number implements java.io.Serializable {
private static final long serialVersionUID = 1927816293512124184L;
// setup to use Unsafe.compareAndSwapLong for updates
// AtomicLong为rt包下的，加载时候使用bootstrap类加载器，所以可以直接使用Unsafe
private static final Unsafe unsafe = Unsafe.getUnsafe();
// 保存了value属性在AtomicLong实例内存的偏移量
private static final long valueOffset;
// 校验JVM是否支持Long类型无所CAS
static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8();
private static native boolean VMSupportsCS8();
static {
try {
// 获取value在AtomicLong中的偏移量
valueOffset = unsafe.objectFieldOffset
(AtomicLong.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
// 实际变量值
private volatile long value;
public AtomicLong(long initialValue) {
value = initialValue;
}
public AtomicLong() {
}
这里提一嘴，value属性用了volatile修饰，保证了多线程下的内存可见性。
下面列出了该类的自增，自减操作：
public final long incrementAndGet() {
return unsafe.getAndAddLong(this, valueOffset, 1L) + 1L;
}
public final long decrementAndGet() {
return unsafe.getAndAddLong(this, valueOffset, -1L) - 1L;
}
public final long getAndIncrement() {
return unsafe.getAndAddLong(this, valueOffset, 1L);
}
public final long getAndDecrement() {
return unsafe.getAndAddLong(this, valueOffset, -1L);
}
getAndAddLong方法源码：
public final long getAndAddLong(Object var1, long var2, long var4) {
long var6;
do {
//获取当前实例的value值（旧值）
var6 = this.getLongVolatile(var1, var2);
} while(!this.compareAndSwapLong(var1, var2, var6, var6 + var4));// 通过CAS操作更新value
// 成功则返回旧值
return var6;
}
如上代码，每个线程都是先拿到value最新的值（value被volatile修饰，内存可见性），然后通过CAS算法去尝试更新value值，如果失败则继续循环进行下一次尝试。
前两个的方法操作都是通过Unsafe来获取value的值，并通过CAS来判断是否可以更新，如果更新成功，则返回自增/自减之后的值。
后两个方法操作则是返回自增/自减之前的旧值。
public final boolean compareAndSet(long expect, long update) {
return unsafe.compareAndSwapLong(this, valueOffset, expect, update);
}
这个方法则是典型的CAS算法，判断当前状态下的实例在valueOffset偏移值上的value属性是否与expect相同，如果相同则使用update更新value，返回true，否则返回false。
总结：如果没有原子操作类，则在多线程下需要通过锁的方式实现操作的原子性，都是阻塞算法，线程的上下文切换消耗大，对性能有一定的损耗，通过非阻塞CAS算法，性能更好，在是高并发情况下AtomicLong还是会存在一些性能问题。
所以对应的LongAdder类应运而生。
LongAdder相关
AtomicLong通过CAS提供了非阻塞的原子性操作，这种做法相比使用阻塞的锁已经很好了，但是在某些高并发下大量的线程会去竞争同一个原子变量，但是由于同时只有一个线程会竞争成功，其他线程只能无限循环不断进行自旋尝试CAS操作，这样子白白浪费了CPU资源。
因此在JDK8中新增了一个原子性递增/递减的操作类LongAdder用来解决在高并发下AtomicLong的缺点。
和之前文章的ThreadLocal本地变量一样类似但又不同，ThreadLocal是每个线程本地维护了一个变量的副本解决了多线程安全问题，而LongAdder则是为了解决多线程同时去竞争一个变量和导致的性能下降，所以把一个变量分解为了多个变量，让同样多的线程去竞争多个资源，就解决了性能问题。
对比一下AtomicLong和LongAdder的不同之处：
由上图，可以看到多个线程同时竞争同一个原子变量，会造成上述的性能下降，而且浪费了CPU的资源。
LongAdder的设计就很巧妙了，在内部，它维护了多个Cell变量（由于Cells的占用内存相对来说比较大，所以只有在需要的时候才创建，这是一种惰性加载的体现），每个Cell里面有一个初始值为0的long变量，这样在同等并发的情况下，争夺单个变量的更新操作就变成了争夺多个变量，变相的减少了争夺共享资源的并发量，需要注意的是：如果某一个线程在争夺某一个Cell一直失败时，他会去其他的Cell变量进行尝试，俗话说：别在一棵树上吊死。这个改变增加了线程重试CAS成功的可能性，最后在获取LongAdder的当前值时，是把所有的Cell变量的value值累加后在加上base返回的。
而且使用了Cell类型之后，通过@sun.misc.Contended也解决了伪共享问题，这个伪共享之后会开一篇文章来总结一下。
下面从源码的角度来理解LongAdder的原理，主要有以下几个问题：
LongAdder的结构是怎样的？当前线程应该访问
cells里面的哪个Cell元素？如何初始化
cells数组？cells数组如何扩容？线程访问分配的
Cell元素有冲突后如何处理？如何保证线程操作被分配的Cell元素的原子性？
首先来看一下LongAdder的UML：
由上图可见，LongAdder继承了Striped64这个类，而这个类中有3个属性时需要我们重点关注的，上图已经用红框标注，分别是cells的一个数组，long类型的base和int类型的cellsBusy。
其中base在上文已经提到了，是一个基础值默认为0，cellsBusy用来实现自旋锁，状态值只有0和1，当创建Cell元素时，扩容Cell数组或者初始化Cell数组时，使用CAS操作变量来保证同时只有一个线程可以进行其中之一的操作。
//（1）
@sun.misc.Contended static final class Cell {
volatile long value; //（2）
Cell(long x) { value = x; }
final boolean cas(long cmp, long val) {
return UNSAFE.compareAndSwapLong(this, valueOffset, cmp, val);
}
// Unsafe mechanics
private static final sun.misc.Unsafe UNSAFE;
private static final long valueOffset;
static {
try {
UNSAFE = sun.misc.Unsafe.getUnsafe();
Class<?> ak = Cell.class;
valueOffset = UNSAFE.objectFieldOffset
(ak.getDeclaredField("value"));
} catch (Exception e) {
throw new Error(e);
}
}
}
（1）该注解解决了伪共享问题，访问了多个元素共享一个CPU的缓存行，在性能上是一个提升
（2）处因为线程操作value的时候没有使用锁，所以使用了volatile修饰保证了内存可见性
到这里我们解决了第1个和第6个问题，并且通过下面的代码可以知道LongAdder的当前值是由基础变量base和cells中元素的value相加得到的。
// 获取LongAdder的当前值
public long sum() {
Cell[] as = cells; Cell a;
long sum = base;
if (as != null) {
for (int i = 0; i < as.length; ++i) {
if ((a = as[i]) != null)
sum += a.value;
}
}
return sum;
}
然后我们来看看方法add(...)
public void add(long x) {
Cell[] as; long b, v; int m; Cell a;
if ((as = cells) != null || !casBase(b = base, b + x)) { // (1)
boolean uncontended = true;
if (as == null || (m = as.length - 1) < 0 || // (2)
(a = as[getProbe() & m]) == null || // (3)
!(uncontended = a.cas(v = a.value, v + x))) // (4)
longAccumulate(x, null, uncontended); // (5)
}
}
final boolean casBase(long cmp, long val) {
return UNSAFE.compareAndSwapLong(this, BASE, cmp, val);
}
static final int getProbe() {
return UNSAFE.getInt(Thread.currentThread(), PROBE);
}
.....
PROBE = UNSAFE.objectFieldOffset(tk.getDeclaredField("threadLocalRandomProbe"));
（1）处的代码条件使用了||短路运算符，判断了cells数组是否为null，所以如果为null则继续执行下一个条件!casBase(b = base, b + x)，caseBase的具体代码则是在当前基础变量的基础上进行CAS累加，这时候就类似AtomicLong的操作。
如果cells数组不为null并且（1）的CAS操作失败了，则进入if分支，执行（2）（3）处的代码，这两处的代码决定了当前线程使用cells数组中的哪一个元素进行操作，如果当前线程映射的元素存在则执行代码（4）,使用CAS去更新分配到的Cell元素的value值，如果映射的元素不存在则执行代码（5）。
总体来看（2）,（3）,（4）就是获取当前线程应该访问的cells中的具体哪一个元素，并且利用CAS更新具体元素的value，如果条件不满足则执行（5）。
其中要访问哪个Cell是通过getProbe() & m（cells数组的长度-1）来计算的。getProbe代码则是通过Unsafe获取了当前线程中的threadLocalRandomProbe属性，这个属性一开始为0，在代码（5）里面会对其进行初始化。在这里回答了问题2。
下面列出longAccumulate(...)的源码，这是cells进行初始化和扩容的地方：
final void longAccumulate(long x, LongBinaryOperator fn,
boolean wasUncontended) {
// （1）初始化当前线程的threadLocalRandomProbe属性
int h;
if ((h = getProbe()) == 0) {
ThreadLocalRandom.current(); // force initialization
h = getProbe();
wasUncontended = true;
}
boolean collide = false; // True if last slot nonempty
for (;;) {
Cell[] as; Cell a; int n; long v;
if ((as = cells) != null && (n = as.length) > 0) { //（2）
if ((a = as[(n - 1) & h]) == null) { // (3)
if (cellsBusy == 0) { // Try to attach new Cell
Cell r = new Cell(x); // Optimistically create
if (cellsBusy == 0 && casCellsBusy()) {
boolean created = false;
try { // Recheck under lock
Cell[] rs; int m, j;
if ((rs = cells) != null &&
(m = rs.length) > 0 &&
rs[j = (m - 1) & h] == null) {
rs[j] = r;
created = true;
}
} finally {
cellsBusy = 0;
}
if (created)
break;
continue; // Slot is now non-empty
}
}
collide = false;
}
else if (!wasUncontended) // CAS already known to fail
wasUncontended = true; // Continue after rehash
// (4) 当前Cell存在，则执行CAS设置
else if (a.cas(v = a.value, ((fn == null) ? v + x :
fn.applyAsLong(v, x))))
break;
//（5）当前cells数组的元素个数大于CPU的个数
else if (n >= NCPU || cells != as)
collide = false; // At max size or stale
//（6） 判断是否有冲突
else if (!collide)
collide = true;
//（7）如果当前元素个数没有达到CPU个数并且有冲突则扩容
else if (cellsBusy == 0 && casCellsBusy()) {
try {
if (cells == as) { // Expand table unless stale
Cell[] rs = new Cell[n << 1];
for (int i = 0; i < n; ++i)
rs[i] = as[i];
cells = rs;
}
} finally {
cellsBusy = 0;
}
collide = false;
continue; // Retry with expanded table
}
//（8）为了能够找到一个空闲的Cell，重新计算Hash值，xorshift算法生成随机数
h = advanceProbe(h);
}
//（9）初始化Cell数组
else if (cellsBusy == 0 && cells == as && casCellsBusy()) {
boolean init = false;
try { // Initialize table
if (cells == as) {
// 9.1
Cell[] rs = new Cell[2];
// 9.2
rs[h & 1] = new Cell(x);
cells = rs;
init = true;
}
} finally {
// 9.3
cellsBusy = 0;
}
if (init)
break;
}
else if (casBase(v = base, ((fn == null) ? v + x :
fn.applyAsLong(v, x))))
break; // Fall back on using base
}
}
很刺激有木有？？？这里我们主要关注问题3，4，5.
当每个线程第一次执行到代码（1）时，会除吃刷当前线程变量threadLocalRandomProbe的值，这个变量在计算当前线程应该被分配到cells数组的哪一个Cell元素时会用到。
在代码（9）处是初始化Cells数组，cellsBusy是一个标示，为0则说明当前cells数组没有被初始化或者扩容，也没有在新建Cell元素，为1则说明cells数组再被初始化或者扩容，或者当前在创建新的Cell元素、通过CAS操作来进行0或者1状态的切换，这里使用了casCellBusy函数。假设当前线程通过CAS设置cellsBusy为1，则当前线程开始初始化操作，其他现线程就不能进行扩容了。
在代码9.1处，初始化cells数组大小为2。
代码9.2处通过threadLocalRandomProbe & 1计算出了当前线程应该访问cell数组的那个位置。
代码9.3处重置了cellsBusy为0，显然这里没有使用CAS，却是线程安全的，这是因为cellsBusy是volatile类型的，这保证了内存可见性，另外此时其他地方的代码是没有机会修改cellsBusy的值。顺便提一嘴，在这里初始化的cells数组里面的两个元素目前还是null，这里问题3就解决了，我们知道了cells数组时如何被初始化的。
接下来说说cells数组的扩容，在代码（5）,（6）,（7）处为cells数组扩容的源码，主要需要注意的就是（5）处判断了cells的元素个数是否小于CPU的个数，这是因为只有当每个CPU运行一个线程时，此时性能才是最佳的，代码（6）处则是判断了是否有同一个线程访问cells中的同一个元素，这个判断是为了避免冲突。所以总结就是当cells元素的个数小于当前机器CPU个数并且当前多个线程访问了cells中的同一个元素，从而导致冲突是其中一个线程CAS失败时才会进行扩容操作。导则立问题4也就明白了。而在其扩容时，也会将cellsBusy通过CAS置换为1。
在代码（8）处，说明线程CAS竞争失败了，所以通过重新计算当前线程的随机值threadLocalRandomProbe，以减少下次访问cells元素时的冲突机会。
到此为止6个问题都解释完了。
总结
本文总结了在JUC包下典型的原子操作类的原理和部分源码，AtomicLong解决了操作的原子性，避免了通过使用锁等阻塞算法带来的性能下降，但是在高并发下还是会存在一定的性能问题，而LongAdder则是在内部维护了一个base变量和一个cells数组，并在获取当前值时通过base和cells数组中的元素和来得到最终的当前值实现的，并且在维护cells数组的扩容行上，考虑了伪共享问题、CPU和执行线程的数量最优问题。
