java之并发包中的原子类

前言

为了避免多线程下由于操作的原子性产生的安全问题，在JDK中的JUC包下提供了一系列使用非阻塞CAS算法实现的原子性操作类，相比使用锁实现的原子性减少了线程的上下文切换，在性能上有了很大的提高。

本文将总结一下JUC下面的一些典型类。

原子变量操作类

在JUC包下，有许多原子性操作类，如图：

JUC包下的一些原子类.png

里面有 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的不同之处：

多线程竞争AtomicLong的情况.png

由上图，可以看到多个线程同时竞争同一个原子变量，会造成上述的性能下降，而且浪费了CPU的资源。

多线程竞争LongAdder的情况.png

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的UML图.png

由上图可见，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和执行线程的数量最优问题。