深入理解CAS和Atomic原子操作类介绍
深入理解CAS
先来看下并发安全的例子
public class CASdemo {
public volatile static int a ;
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
new Thread(new Runnable() {
@Override
public void run() {
for (int j = 0; j < 10000; j++) {
a++;
}
}
}).start();
}
try {
Thread.sleep(3000);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(a);
}
}
开启10个线程，每个线程对a累加一万次，a前面定义了volatile，保证了可见性和有序性。如果是线程安全的情况下，结果就是10万，那么来看看实际结果
之前也说过volatile 不保证原子性，而a++操作并不是原子性操作。如果上述代码要保证线程安全可以通过加锁或者通过CAS来实现。
现在来了解什么是CAS
CAS（Compare And Swap，比较并交换）
通常指的是这样一种原子操作：针对一个变量，首先比较它的内存值与某个期望值是否相同，如果相同，就给它赋一个新值。 CAS 的逻辑用伪代码描述如下
if(v == e){
v = u
}
以上伪代码描述了一个由比较和赋值两阶段组成的复合操作，CAS 可以看作是它们合并后的整体 一个不可分割的原子操作，并且其原子性是直接在硬件层面得到保障的。
CAS可以看做是乐观锁（对比数据库的悲观、乐观锁）的一种实现方式，Java原子类中的递增操作就通过CAS自旋实现的。 CAS是一种无锁算法，在不使用锁（没有线程被阻塞）的情况下实现多线程之间的变量同步。
CAS的过程如下图
在开始的时候读取V的值赋值给E。当V需要进行修改的时候，再从内存中读取最新的V和E，如果相等那么V==U，并且返回旧的V值(旧V和U交换)。如果不相等V不能修改，然后返回U的值(U没有被交换)。
CAS在java中的应用
在 Java 中，CAS 操作是由Unsafe类提供支持的，该类定义了三种针对不同类型变量的CAS操作，如图
它们都是 native 方法，由 Java 虚拟机提供具体实现，这意味着不同的 Java 虚拟机对它们的实现可能会略有不同。
以compareAndSwapInt为例，Unsafe的compareAndSwapInt方法接收4个参数，分别是：对象实例、内存偏移量、字段期望值、字段新值。该方法会针对指定对象实例中的相应偏移量的字段执行CAS操作。
public class CASTest {
public static void main(String[] args) {
Entity entity = new Entity();
Unsafe unsafe = UnsafeFactory.getUnsafe();
//获取x的内存偏移量
long offset = UnsafeFactory.getFieldOffset(unsafe, Entity.class, "x");
boolean successful;
// 4个参数分别是：对象实例、字段的内存偏移量、字段期望值、字段更新值
successful = unsafe.compareAndSwapInt(entity, offset, 0, 3);
System.out.println(successful + "\t" + entity.x);
successful = unsafe.compareAndSwapInt(entity, offset, 3, 5);
System.out.println(successful + "\t" + entity.x);
successful = unsafe.compareAndSwapInt(entity, offset, 3, 8);
System.out.println(successful + "\t" + entity.x);
}
}
class Entity{
int x;
}
上面代码意思是：首先拿到Unsafe，获取需要CAS操作的变量的内存偏移量。然后通过compareAndSwapInt方法进行CAS操作。如果x的值等于0，那么更新为3，如果x的值等于3那么更新为5，如果x的值等于3更新为8。看下结果
int x的默认值为0 ，那么0等于0，所以x可以更新为3，然后x等于3，可以更新为5，然后x不等于3，因此不能更新为8，所以x=5。
CAS源码分析
上面说过CAS的伪代码是先比较，然后在交换。那么如何保证原子性。在硬件层面上对于这个伪代码是原子性，就是说CAS在硬件层面保证了原子性。但是光保证原子性就能保证线程安全了吗，还需要保证可见性和有序性。在硬件层面上CAS是不保证有序性和可见性的，只保证了原子性，但是在java层面做了处理。CAS的过程中说到，比较交换后，成功返回旧值，失败返回新值。但是在java中的Unsafe类中定义的三种针CAS操作返回的是boolean类型。它是在jvm层面做了处理。既然能在jvm层面做了处理，自然也能够在jvm层面保证可见性和有序性。
之前说过lock前缀指令能够保证有序性和可见性。jvm底层就是通过lock前缀指令再加上CAS指令。来看下源码
Hotspot 虚拟机对compareAndSwapInt 方法的实现如下：
#unsafe.cpp
UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
UnsafeWrapper("Unsafe_CompareAndSwapInt");
oop p = JNIHandles::resolve(obj);
// 根据偏移量，计算value的地址
jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);
//Atomic::cmpxchg(x, addr, e) cas逻辑 x:要交换的值 e:要比较的值
//cas成功，返回期望值e，等于e,此方法返回true
//cas失败，返回内存中的value值，不等于e，此方法返回false
return (jint)(Atomic::cmpxchg(x, addr, e)) == e;
先解释下偏移量：java创建对象是放在堆空间，对象头占8个字节，压缩指针占4个字节，加上数据的字节，最后对齐填充保证是8的整数倍。例如上面案例中Entity的int x 占4个字节，对象头和指针一共12个字节，那么一个Entity类的对象占16个字节。那么x偏移量就是从12开始。
unsafe定义的CAS返回值是boolean类型，如果Atomic::cmpxchg(x, addr, e)的返回值等于e，则返回true，如果不等于则返回false。e是期望值，x是要更新的值。
核心逻辑在Atomic::cmpxchg方法中，这个根据不同操作系统和不同CPU会有不同的实现。这里我们以linux_64x的为例，查看Atomic::cmpxchg的实现
#atomic_linux_x86.inline.hpp
inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
//判断当前执行环境是否为多处理器环境
int mp = os::is_MP();
//LOCK_IF_MP(%4) 在多处理器环境下，为 cmpxchgl 指令添加 lock 前缀，以达到内存屏障的效果
//cmpxchgl 指令是包含在 x86 架构及 IA-64 架构中的一个原子条件指令，
//它会首先比较 dest 指针指向的内存值是否和 compare_value 的值相等，
//如果相等，则双向交换 dest 与 exchange_value，否则就单方面地将 dest 指向的内存值交给exchange_value。
//这条指令完成了整个 CAS 操作，因此它也被称为 CAS 指令。
__asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
: "=a" (exchange_value)
: "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
: "cc", "memory");
return exchange_value;
现代处理器指令集架构基本上都会提供 CAS 指令，例如 x86 和 IA-64 架构中的 cmpxchgl 指令 和 comxchgq 指令，sparc 架构中的 cas 指令和 casx 指令。
不管是 Hotspot 中的 Atomic::cmpxchg 方法，还是 Java 中的 compareAndSwapInt 方法，它们本质上都是对相应平台的 CAS 指令的一层简单封装。CAS 指令作为一种硬件原语，有着天然的原子性，这也正是 CAS 的价值所在。
了解CAS以后，对于第一个案例，如果通过CAS实现线程安全要怎么做，首先定义一个CAS的工具类
public class UnsafeFactory {
/**
* 获取 Unsafe 对象
* @return
*/
public static Unsafe getUnsafe() {
try {
Field field = Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
return (Unsafe) field.get(null);
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
/**
* 获取字段的内存偏移量
* @param unsafe
* @param clazz
* @param fieldName
* @return
*/
public static long getFieldOffset(Unsafe unsafe, Class clazz, String fieldName) {
try {
return unsafe.objectFieldOffset(clazz.getDeclaredField(fieldName));
} catch (NoSuchFieldException e) {
throw new Error(e);
}
}
}
public class CASLock {
//加锁标记
private volatile int state;
private static final Unsafe UNSAFE;
//偏移量
private static final long OFFSET;
static {
try {
//通过工厂获取UNSAFE类
UNSAFE = UnsafeFactory.getUnsafe();
//获取偏移量
OFFSET = UnsafeFactory.getFieldOffset(
UNSAFE, CASLock.class, "state");
} catch (Exception e) {
throw new Error(e);
}
}
public boolean cas() { //CAS操作
//如果state==0 则能够把state更新为1，CAS成功
return UNSAFE.compareAndSwapInt(this, OFFSET, 0, 1);
}
public int getState() {
return state;
}
public void setState(int state) {
this.state = state;
}
}
第一个案例代码修改为
public volatile static int a ;
public static final CASLockT lock = new CASLockT();
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
new Thread(new Runnable() {
@Override
public void run() {
for (;;){//失败自旋
if (lock.cas()){//CAS成功执行下面的代码
for (int j = 0; j < 10000; j++) {
a++;
}
//业务执行完成将state的还原0，让其他线程能够CAS成功
lock.setState(0);
//退出自旋
break;
}
}
}
}).start();
}
try {
Thread.sleep(3000);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(a);
}
这样就通过CAS保证线程安全，不过这样是有问题，CAS在不断自旋的过程中，会大量消耗CPU的资源。这是自己手写的一个CAS操作。不过在java中在J.U.C下的atomic包提供了一系列的操作简单， 性能高效基本类型变量等。在将上面的代码进行修改
public class CASdemo1 {
public static AtomicInteger a = new AtomicInteger();
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
new Thread(() -> {
for (int j = 0; j < 10000; j++) {
a.incrementAndGet();
}
}).start();
}
try {
Thread.sleep(3000);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(a);
}
}
CAS缺陷
CAS 虽然高效地解决了原子操作，但是还是存在一些缺陷的，主要表现在三个方面：
- 自旋 CAS 长时间地不成功，则会给 CPU 带来非常大的开销
- 只能保证一个共享变量原子操作
- ABA 问题
重点来看下ABA问题。什么是ABA问题？
当有多个线程对一个原子类进行操作的时候，某个线程在短时间内将原子类的值A修改为B，又马 上将其修改为A，此时其他线程不感知，还是会修改成功。
比如上图，期望值是10，Thread2修改为20，然后Thread3将20修改为10，那么Thread1做CAS操作的时候读取到10和期望值相比较，相同CAS成功，实际上Thread2已经对原值进行了修改，但CAS感知不到，认为没有修改过。
这样会造成什么问题，比如说有100万存在银行，那么一开始期望值是100万，此时别人把100万私自挪走，利用这100万赚了钱，在把100万存回银行，此时银行对账发现100万还在，没有其他人使用过这100万。这样就会造成很大的漏洞。
测试ABA问题
@Slf4j
public class ABATest {
public static void main(String[] args) {
AtomicInteger atomicInteger = new AtomicInteger(1);
new Thread(()->{
int value = atomicInteger.get();
log.debug("Thread1 read value: " + value);
// 阻塞1s
LockSupport.parkNanos(1000000000L);
// Thread1通过CAS修改value值为3
if (atomicInteger.compareAndSet(value, 3)) {
log.debug("Thread1 update from " + value + " to 3");
} else {
log.debug("Thread1 update fail!");
}
},"Thread1").start();
new Thread(()->{
int value = atomicInteger.get();
log.debug("Thread2 read value: " + value);
// Thread2通过CAS修改value值为2
if (atomicInteger.compareAndSet(value, 2)) {
log.debug("Thread2 update from " + value + " to 2");
// do something
value = atomicInteger.get();
log.debug("Thread2 read value: " + value);
// Thread2通过CAS修改value值为1
if (atomicInteger.compareAndSet(value, 1)) {
log.debug("Thread2 update from " + value + " to 1");
}
}
},"Thread2").start();
}
Thread1不清楚Thread2对value的操作，误以为value=1没有修改过
ABA问题的解决方案
数据库有个乐观锁，是一种基于数据版本实现数据同步的机制，每次修改一次数据，版本就会进行累加。 同样，Java也提供了相应的原子引用类AtomicStampedReference
//AtomicStampedReference部分源码
public class AtomicStampedReference<V> {
private static class Pair<T> {
final T reference;
final int stamp;//类似于版本号
private Pair(T reference, int stamp) {
this.reference = reference;
this.stamp = stamp;
}
static <T> Pair<T> of(T reference, int stamp) {
return new Pair<T>(reference, stamp);
}
}
private volatile Pair<V> pair;
reference即我们实际存储的变量，stamp是版本，每次修改可以通过+1保证版本唯一性。这样 就可以保证每次修改后的版本也会往上递增。
ABA案例代码的解决
@Slf4j
public class AtomicStampedReferenceTest {
public static void main(String[] args) {
// 定义AtomicStampedReference Pair.reference值为1, Pair.stamp为1
AtomicStampedReference atomicStampedReference = new AtomicStampedReference(1,1);
new Thread(()->{
int[] stampHolder = new int[1];
int value = (int) atomicStampedReference.get(stampHolder);
int stamp = stampHolder[0];
log.debug("Thread1 read value: " + value + ", stamp: " + stamp);
// 阻塞1s
LockSupport.parkNanos(1000000000L);
// Thread1通过CAS修改value值为3
if (atomicStampedReference.compareAndSet(value, 3,stamp,stamp+1)) {
log.debug("Thread1 update from " + value + " to 3");
} else {
log.debug("Thread1 update fail!");
}
},"Thread1").start();
new Thread(()->{
int[] stampHolder = new int[1];
int value = (int)atomicStampedReference.get(stampHolder);
int stamp = stampHolder[0];
log.debug("Thread2 read value: " + value+ ", stamp: " + stamp);
// Thread2通过CAS修改value值为2
if (atomicStampedReference.compareAndSet(value, 2,stamp,stamp+1)) {
log.debug("Thread2 update from " + value + " to 2");
// do something
value = (int) atomicStampedReference.get(stampHolder);
stamp = stampHolder[0];
log.debug("Thread2 read value: " + value+ ", stamp: " + stamp);
// Thread2通过CAS修改value值为1
if (atomicStampedReference.compareAndSet(value, 1,stamp,stamp+1)) {
log.debug("Thread2 update from " + value + " to 1");
}
}
},"Thread2").start();
}
Thread1并没有成功修改value
Atomic原子操作类介绍
在J.U.C下的atomic包提供了一系列的操作简单， 性能高效，并能保证线程安全的类去更新基本类型变量，数组元素，引用类型以及更新对象中的 字段类型。atomic包下的这些类都是采用的是乐观锁策略去原子更新数据，在java中则是使用 CAS操作具体实现。
在java.util.concurrent.atomic包里提供了一组原子操作类：
- 基本类型：AtomicInteger、AtomicLong、AtomicBoolean；
- 引用类型：AtomicReference、AtomicStampedRerence、AtomicMarkableReference；
- 数组类型：AtomicIntegerArray、AtomicLongArray、AtomicReferenceArray
- 对象属性原子修改器：AtomicIntegerFieldUpdater、AtomicLongFieldUpdater、 - AtomicReferenceFieldUpdater
- 原子类型累加器（jdk1.8增加的类）：DoubleAccumulator、DoubleAdder、 LongAccumulator、LongAdder、Striped64
原子更新基本类型
以AtomicInteger为例总结常用的方法。AtomicInteger在上面的案例中有使用过，具体来分析自增的代码。
使用到了do while 循环。不断的自旋直到CAS成功。
原子更新数组类型
AtomicIntegerArray为例总结常用的方法
//addAndGet(int i, int delta)：以原子更新的方式将数组中索引为i的元素与输入值相加；
public final int addAndGet(int i, int delta) {
return getAndAdd(i, delta) + delta;
}
//getAndIncrement(int i)：以原子更新的方式将数组中索引为i的元素自增加1；
public final int getAndIncrement(int i) {
return getAndAdd(i, 1);
}
//compareAndSet(int i, int expect, int update)：将数组中索引为i的位置的元素进行更新
public final boolean compareAndSet(int i, int expect, int update) {
return compareAndSetRaw(checkedByteOffset(i), expect, update);
public class AtomicArrayDemo {
public static int[] arr = {1, 2, 3, 4, 5};
public static AtomicIntegerArray atomicIntegerArray = new AtomicIntegerArray(arr);
public static void main(String[] args) {
//指定下标放入数据
atomicIntegerArray.set(0,100);
System.out.println(atomicIntegerArray.get(0));
//以原子更新的方式将数组中索引为1的元素与输入值相加 返回值是旧的值
int a = atomicIntegerArray.getAndAdd(1, 5);
System.out.println(a);
System.out.println(atomicIntegerArray);
}
}
原子更新引用类型
AtomicReference作用是对普通对象的封装，它可以保证你在修改对象引用时的线程安全性。
public class AtomicRefdemo {
public static void main(String[] args) {
User user1 = new User("张三", 23);
User user2 = new User("李四", 25);
User user3 = new User("王五", 20);
//初始化为 user1
AtomicReference<User> atomicReference = new AtomicReference<>();
atomicReference.set(user1);
//把 user2 赋给 atomicReference 第一个参数期望值，第二个参数修改值
//CAS成功
atomicReference.compareAndSet(user1, user2);
System.out.println(atomicReference.get());
//把 user3 赋给 atomicReference
//CAS失败
atomicReference.compareAndSet(user1, user3);
System.out.println(atomicReference.get());
}
}
对象属性原子修改器
AtomicIntegerFieldUpdater可以线程安全地更新对象中的整型变量
public class AtomicFileUpdateDemo {
public static class Candidate {
volatile int score = 0;
AtomicInteger score2 = new AtomicInteger();
}
//第一个参数类对象，第二个参数需要修改的属性变量名(注意必须是volatile修饰的)
public static final AtomicIntegerFieldUpdater<Candidate> scoreUpdater =
AtomicIntegerFieldUpdater.newUpdater(Candidate.class, "score");
public static AtomicInteger realScore = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
final Candidate candidate = new Candidate();
Thread[] t = new Thread[10000];
//循环生成多线程
for (int i = 0 ; i < 10000 ; i++){
t[i] = new Thread(() -> {
if (Math.random() > 0.4){
//不同方式的自增
candidate.score2.incrementAndGet();
scoreUpdater.incrementAndGet(candidate);
realScore.incrementAndGet();
}
});
t[i].start();
}
//main线程阻塞，等待其他线程执行完成
for (int i = 0 ; i < 10000 ; i++){
t[i].join();
}
//三种自增方式的结果是一样的
System.out.println("AtomicIntegerFieldUpdater Score=" + candidate.score);
System.out.println("AtomicInteger Score=" + candidate.score2.get());
System.out.println("realScore=" + realScore.get());
}
}
对于AtomicIntegerFieldUpdater的使用稍微有一些限制和约束，约束如下：
（1）字段必须是volatile类型的，在线程之间共享变量时保证立即可见.eg:volatile int value = 3
（2）字段的描述类型（修饰符public/protected/default/private）与调用者与操作对象字段的关系一致。也就是说调用者能够直接操作对象字段，那么就可以反射进行原子操作。但是对于父类的字段，子类是不能直接操作的，尽管子类可以访问父类的字段。
（3）只能是实例变量，不能是类变量，也就是说不能加static关键字。
（4）只能是可修改变量，不能使final变量，因为final的语义就是不可修改。实际上final的语义和 volatile是有冲突的，这两个关键字不能同时存在。
（5）对于AtomicIntegerFieldUpdater和AtomicLongFieldUpdater只能修改int/long类型的字段，不能修改其包装类型（Integer/Long）。如果要修改包装类型就需要使用 AtomicReferenceFieldUpdater。
LongAdder/DoubleAdder详解
重点来了解这两个。在高并发的场景下，同时操作一个数值，肯定有性能问题的。比如说高并发下对V的值进行++的操作，同一时刻只能有一个线程可以对A进行操作，其他线程不断自旋。这样会损耗性能，不断的抢占CPU的时间片。那有什么好的办法呢？
当多个线程同时对一个V操作确实会有这种情况，但是如果多个线程对多个V同时进行操作，然后多个V相加，这样就会好一点。
像之前的AtomicLong，在并发量较低的环境下，线程冲突的概率比较小，自旋的次数不会很多。但是，高并发环境下， N个线程同时进行自旋操作，会出现大量失败并不断自旋的情况，此时AtomicLong的自旋会成为瓶颈。
这就是LongAdder引入的初衷——解决高并发环境下AtomicInteger， AtomicLong的自旋瓶颈问题。
看一个测试代码
public class LongAdderDemo {
public static void main(String[] args) {
testAtomicLongVSLongAdder(10, 10000);
System.out.println("==================");
testAtomicLongVSLongAdder(10, 200000);
System.out.println("==================");
testAtomicLongVSLongAdder(100, 200000);
}
static void testAtomicLongVSLongAdder(final int threadCount, final int times) {
try {
//测试atomicLong并发下++的需要的时间
long start = System.currentTimeMillis();
testLongAdder(threadCount, times);
long end = System.currentTimeMillis() - start;
System.out.println("条件>>>>>>线程数:" + threadCount + ", 单线程操作计数" + times);
System.out.println("结果>>>>>>LongAdder方式增加计数" + (threadCount * times) + "次,共计耗时:" + end);
//测试testLongAdder并发下++的需要的时间
long start2 = System.currentTimeMillis();
testAtomicLong(threadCount, times);
long end2 = System.currentTimeMillis() - start2;
System.out.println("条件>>>>>>线程数:" + threadCount + ", 单线程操作计数" + times);
System.out.println("结果>>>>>>AtomicLong方式增加计数" + (threadCount * times) + "次,共计耗时:" + end2);
} catch (Exception e) {
e.printStackTrace();
}
}
static void testAtomicLong(final int threadCount, final int times) throws InterruptedException {
CountDownLatch countDownLatch = new CountDownLatch(threadCount);
AtomicLong atomicLong = new AtomicLong();
for (int i = 0; i < threadCount; i++) {
new Thread(() -> {
for (int j = 0; j < times; j++) {
atomicLong.incrementAndGet();
}
countDownLatch.countDown();
}, "my‐thread" + i).start();
}
countDownLatch.await();
}
static void testLongAdder(final int threadCount, final int times) throws InterruptedException {
CountDownLatch countDownLatch = new CountDownLatch(threadCount);
LongAdder longAdder = new LongAdder();
for (int i = 0; i < threadCount; i++) {
new Thread(() -> {
for (int j = 0; j < times; j++) {
longAdder.add(1);
}
countDownLatch.countDown();
}, "my‐thread" + i).start();
}
countDownLatch.await();
}
}
看下运行结果：
在10个线程并发的情况下每个线程累加1万次，AtomicLong的性能要比LongAdder要高。但是如果累加2万次，LongAdder的性能就要比AtomicLong要高。在100个线程并发下每个线程累加20万，LongAdder的性能就要比AtomicLong高出一个数量级。
测试结果：线程数越多，并发操作数越大，LongAdder的优势越明显。
低并发、一般的业务场景下AtomicLong是足够了。如果并发量很多，存在大量写多读少的情况，那LongAdder可能更合适。
LongAdder原理
AtomicLong中有个内部变量value保存着实际的long值，所有的操作都是针对该变量进行。也就是说，高并发环境下，value变量其实是一个热点，也就是N个线程竞争 一个热点。LongAdder的基本思路就是分散热点，将value值分散到一个数组中，不同线程会命中到数组的不同槽中，各个线程只对自己槽中的那个值进行CAS操作，这样热点就被分散了，冲突的概率就小很多。如果要获取真正的long值，只要将各个槽中的变量值累加返回。
LongAdder的内部结构
LongAdder内部有一个base变量，一个Cell[]数组：
base变量：非竞态条件下，直接累加到该变量上
Cell[]数组：竞态条件下，累加个各个线程自己的槽Cell[i]中
NCPU:CPU核数，用来决定槽数组的大小
cell: 数组槽
base: 基数，在两种情况下会使用：1. 没有遇到并发竞争时，直接使用base累加数值 2. 初始化cells数组时，必须要保证cells数组只能被初始化一次（即只有一个线程能对cells初始化） 其他竞争失败的线程会讲数值累加到base上
LongAdder#add方法的逻辑流程图
只有从未出现过并发冲突的时候，base基数才会使用到，一旦出现了并发冲突，之后所有的操作都只针对Cell[]数组中的单元Cell。 如果Cell[]数组未初始化，会调用父类的longAccumelate去初始化Cell[]，如果Cell[]已经初始化但是冲突发生在Cell单元内，则也调用父类的longAccumelate，此时可能就需要对Cell[]扩容 了。这也是LongAdder设计的精妙之处：尽量减少热点冲突，不到最后万不得已，尽量将CAS操作延迟。
Striped64#longAccumulate方法流程图
LongAdder#sum方法
/**
* 返回累加的和，也就是"当前时刻"的计数值
* 注意： 高并发时，除非全局加锁，否则得不到程序运行中某个时刻绝对准确的值
* 此返回值可能不是绝对准确的，因为调用这个方法时还有其他线程可能正在进行计数累加,
* 方法的返回时刻和调用时刻不是同一个点，在有并发的情况下，这个值只是近似准确的计数值
*/
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;
由于计算总和时没有对Cell数组进行加锁，所以在累加过程中可能有其他线程对Cell中的值进行了修改，也有可能对数组进行了扩容，所以sum返回的值并不是非常精确的，其返回值并不是一个调用sum方法时的原子快照值。
LongAccumulator
LongAccumulator是LongAdder的增强版。LongAdder只能针对数值的进行加减运算，而 LongAccumulator提供了自定义的函数操作。
通过LongBinaryOperator，可以自定义对入参的任意操作，并返回结果（LongBinaryOperator接收2个long作为参数，并返回1个long）。LongAccumulator内部原理和LongAdder几乎完全一样，都是利用了父类Striped64的longAccumulate方法。
1568
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
