JUC LongAdder高性能

在Jdk8以后推荐使用LongAdder替代AtomicLong,减少等待。

为什么LongAdder这么快

LongAdder基本思路就是分散热点，将value分散到各自cell里面，不同线程会命中不同槽中，每一个槽中都是cas 乐观锁，达到分而治之。核心思想就是把之前的AtomicLong一个value更新压力分散到不同槽里面。

为了更好地对源码进行分析，我们需要先从直觉上理解它的原理，否则直接看代码的话会一脸懵逼

LongAdder的计数主要分为2个对象

一个long类型的字段：base

一个Cell对象数组，Cell对象中就维护了一个long类型的字段value，用来计数

/** * Table of cells. When non-null, size is a power of 2. */transient volatile Cell[] cells;/** * Base value, used mainly when there is no contention, but also as * a fallback during table initialization races. Updated via CAS. */transient volatile long base;

当没有发生线程竞争的时候，累加都会发生在base字段上，这就相当于是一个单线程累加2次，只不过base的累加是一个cas操作

当发生线程竞争的时候，必然有一个线程对base的cas累加操作失败，于是它先去判断Cell是否已经被初始化了，如果没有则初始化一个长度为2的数组，并根据线程的hash值找到对应的数组索引，并对该索引的Cell对象中的value值进行累加（这个累加也是cas的操作）

如果一共有3个线程发生了竞争，那么其中第一个线程对base的cas累加成功，剩下2个线程都需要去对Cell数组中的元素进行累加。因为对Cell中value值的累加也是一个cas操作，如果第二个线程和第三个线程的hash值对应的数组下标是同一个，那么同样会发生竞争，如果第二个线程成功了，第三个线程就会去rehash自己的hash值，如果得到的新的hash值对应的是另一个元素为null的数组下标，那么就new一个Cell对象并对value值进行累加

如果此时有线程4同时参与竞争，那么对于线程4来说，即使rehash后还是可能在和线程3的竞争过程中cas失败，此时如果当前数组的容量小于系统可用的cpu的数量，那么它就会对数组进行扩容，之后再次rehash，重复尝试对Cell数组中某个下标对象的累加

以上就是整体直觉上的理解，然而代码中还有很多细节的设计非常值得学习，所以我们就开始进入源码分析的环节