一、前言

本次分享我们来共同探讨JUC包中一些有意思的类，包含AtomicLong & LongAdder,ThreadLocalRandom原理。

二、AtomicLong & LongAdder

2.1 AtomicLong 类

AtomicLong是JUC包提供的原子性操作类，其内部通过CAS保证了对计数的原子性更新操作。

大家可以翻看源码发现内部是通过UnSafe(rt.jar)这个类的CAs操作来保证对内部的计数器变量 long value进行原子性更新的，比如JDK8中：

    public final long incrementAndGet() {
        return unsafe.getAndAddLong(this, valueOffset, 1L) + 1L;
    }

其中unsafe.getAndAddLong的代码如下：

  public final long getAndAddLong(Object paramObject, long paramLong1, long paramLong2)
  {
    long l;
    do
    {
      l = getLongVolatile(paramObject, paramLong1);//(1)
    } while (!compareAndSwapLong(paramObject, paramLong1, l, l + paramLong2));//(2)
    return l;
  }

可知最终调用的是native 方法compareAndSwapLong原子性操作。

当多个线程调用同一个AtomicLong实例的incrementAndGet方法后，多个线程都会执行到unsafe.getAndAddLong方法，然后多个线程都会执行到代码（1）处获取计数器的值，然后都会去执行代码（2），如果多个线程同时执行了代码（2），由于CAS具有原子性，所以只有一个线程会更新成功，然后返回true从而退出循环，整个更新操作就OK了。其他线程则CAS失败返回false，则循环一次在次从（1）处获取当前计数器的值，然后在尝试执行（2），这叫做CAS的自旋操作，本质是使用Cpu 资源换取使用锁带来的上下文切换等开销。

2.2 LongAdder类

AtomicLong类为开发人员使用线程安全的计数器提供了方便，但是AtomicLong在高并发下存在一些问题，如上所述，当大量线程调用同一个AtomicLong的实例的方法时候，同时只有一个线程会CAS计数器的值成功，失败的线程则会原地占用cpu进行自旋转重试，这回造成大量线程白白浪费cpu原地自旋转。

在JDK8中新增了一个LongAdder类，其采用分而治之的策略来减少同一个变量的并发竞争度,LongAdder的核心思想是把一个原子变量分解为多个变量，让同样多的线程去竞争多个资源，这样竞争每个资源的线程数就被分担了下来，下面通过图形来理解下两者设计的不同之处：

如上图AtomicLong是多个线程同时竞争同一个原子变量。

如上图LongAdder内部维护多个Cell变量，在同等并发量的情况下，争夺单个变量更新操作的线程量会减少，这是变相的减少了争夺共享资源的并发量。

下面我们首先看下Cell的结构：

    @sun.misc.Contended static final class Cell {
        volatile long value;
        Cell(long x) { value = x; }
        final boolean cas(long cmp, long val) {
            return UNSAFE.compareAndSwapLong(this, valueOffset, cmp, val);
        }

        // Unsafe 机制
        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);
            }
        }
    }

LongAdder维护了一个延迟初始化的原子性更新数组（默认情况下Cell数组是null）和一个基值变量base，由于Cells占用内存是相对比较大的，所以一开始并不创建，而是在需要时候在创建，也就是惰性 创建。

当一开始判断cell数组是null并且并发线程较少时候所有的累加操作都是对base变量进行的，这时候就退化为了AtomicLong。cell数组的大小保持是2的N次方大小，初始化时候Cell数组的中Cell的元素个数为2，数组里面的变量实体是Cell类型。

当多个线程在争夺同一个Cell原子变量时候如果失败并不是在当前cell变量上一直自旋CAS重试，而是会尝试在其它Cell的变量上进行CAS尝试，这个改变增加了当前线程重试时候CAS成功的可能性。最后获取LongAdder当前值的时候是把所有Cell变量的value值累加后在加上base返回的，如下代码：

    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;
    }

如上代码可知首先把base的值赋值给sum变量，然后通过循环把每个cell元素的value值累加到sum变量上，最后返回sum.

其实这是一种分而治之的策略，先把并发量分担到多个原子变量上，让多个线程并发的对不同的原子变量进行操作，然后获取计数时候在把所有原子变量的计数和累加。

思考问题：

• 何时初始化cell数组
• 当前线程如何选择cell中的元素进行访问
• 如果保证cell中元素更新的线程安全
• cell数组何时进行扩容，cell元素个数可以无限扩张?

性能对比，这里有一个文章
http://blog.palominolabs.com/2014/02/10/java-8-performance-improvements-longadder-vs-atomiclong/

三、 Random & ThreadLocalRandom

3.1 Random类原理及其局限性

在JDK7之前包括现在java.util.Random应该是使用比较广泛的随机数生成工具类,下面先通过简单的代码看看java.util.Random是如何使用的：

public class RandomTest {
    public static void main(String[] args) {

        //(1)创建一个默认种子的随机数生成器
        Random random = new Random();
        //(2)输出10个在0-5（包含0，不包含5）之间的随机数
        for (int i = 0; i < 10; ++i) {
            System.out.println(random.nextInt(5));
        }
    }
}

• 代码（1）创建一个默认随机数生成器，使用默认的种子。
• 代码（2）输出输出10个在0-5（包含0，不包含5）之间的随机数。

    public int nextInt(int bound) {
        //(3)参数检查
        if (bound <= 0)
            throw new IllegalArgumentException(BadBound);
        //(4)根据老的种子生成新的种子
        int r = next(31);
        //(5)根据新的种子计算随机数
        ...
        return r;
    } 

如上代码可知新的随机数的生成需要两个步骤

• 首先需要根据老的种子计算生成新的种子。
• 然后根据新的种子和bound变量通过一定的算法来计算新的随机数。

下面看下next()代码：

    protected int next(int bits) {
        long oldseed, nextseed;
        AtomicLong seed = this.seed;
        do {
            //(6)获取当前原子变量种子的值
            oldseed = seed.get();
            //(7)根据当前种子值计算新的种子
            nextseed = (oldseed * multiplier + addend) & mask;
            //(8)使用新种子替换老的种子
        } while (!seed.compareAndSet(oldseed, nextseed));
        //(9)
        return (int)(nextseed >>> (48 - bits));
    }

• 代码（6）使用原子变量的get方法获取当前原子变量种子的值
• 代码（7）根据具体的算法使用当前种子值计算新的种子
• 代码（8）使用CAS操作，使用新的种子去更新老的种子，多线程下可能多个线程都同时执行到了代码（6）那么可能多个线程都拿到的当前种子的值是同一个，然后执行步骤（7）计算的新种子也都是一样的，但是步骤（8）的CAS操作会保证只有一个线程可以更新老的种子为新的，失败的线程会通过循环从新获取更新后的种子作为当前种子去计算老的种子,这就保证了随机数的随机性。
• 代码（9）则使用固定算法根据新的种子计算随机数，并返回。

3.2 ThreadLocalRandom

Random类生成随机数原理以及不足：每个Random实例里面有一个原子性的种子变量用来记录当前的种子的值，当要生成新的随机数时候要根据当前种子计算新的种子并更新回原子变量。

多线程下使用单个Random实例生成随机数时候，多个线程同时计算随机数计算新的种子时候多个线程会竞争同一个原子变量的更新操作，由于原子变量的更新是CAS操作，同时只有一个线程会成功，那么CAS操作失败的大量线程进行自旋重试，而大量线程的自旋重试是会降低并发性能和消耗CPU资源的，为了解决这个问题，ThreadLocalRandom类应运而生。

public class RandomTest {

    public static void main(String[] args) {
        //(10)获取一个随机数生成器
        ThreadLocalRandom random =  ThreadLocalRandom.current();

        //(11)输出10个在0-5（包含0，不包含5）之间的随机数
        for (int i = 0; i < 10; ++i) {
            System.out.println(random.nextInt(5));
        }
    }
}

如上代码（10）调用ThreadLocalRandom.current()来获取当前线程的随机数生成器。下面来分析下ThreadLocalRandom的实现原理。

从名字看会让我们联想到ThreadLocal类。ThreadLocal通过让每一个线程拷贝一份变量，每个线程对变量进行操作时候实际是操作自己本地内存里面的拷贝，从而避免了对共享变量进行同步。实际上ThreadLocalRandom的实现也是这个原理。Random的缺点是多个线程会使用原子性种子变量，会导致对原子变量更新的竞争，这个原理可以通过下面图来表达：

那么如果每个线程维护自己的一个种子变量，每个线程生成随机数时候根据自己本地内存中的老的种子计算新的种子，并使用新种子更新老的种子，然后根据新种子计算随机数，就不会存在竞争问题，这会大大提高并发性能，如下图ThreadLocalRandom原理可以使用下图表达：

Thread类里面有几个变量：

    /** The current seed for a ThreadLocalRandom */
    @sun.misc.Contended("tlr")
    long threadLocalRandomSeed;

    /** Probe hash value; nonzero if threadLocalRandomSeed initialized */
    @sun.misc.Contended("tlr")
    int threadLocalRandomProbe;

思考问题：

• 每个线程的初始种子怎么生成的
• 如果保障多个线程产生的种子不一样

四、总结

本文摘自 Java 并发编程之美 一书，具体可以单击阅读原文。其实JUC包中还有其他一些经典的组件，比如fork-join框架等，这个后面有时间我们在一块讨论。