共计 5110 个字符，预计需要花费 13 分钟才能阅读完成。
一、前言
本次分享我们来共同探讨 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 并发编程之美 一书中有关章节的提炼。本次分享首先讲解了 AtomicLong 的内部实现，以及存在的缺点，然后讲解了 LongAdder 采用分而治之的策略通过使用多个原子变量减小单个原子变量竞争的并发度。然后简单介绍了 Random，和其缺点，最后介绍了 ThreadLocalRandom 借用 ThreadLocal 的思想解决了多线程对同一个原子变量竞争锁带来的性能损耗。其实 JUC 包中还有其他一些经典的组件，比如 fork-join 框架等。
本文作者：加多阅读原文
本文为云栖社区原创内容，未经允许不得转载。
