在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数组中某个下标对象的累加
以上就是整体直觉上的理解,然而代码中还有很多细节的设计非常值得学习,所以我们就开始进入源码分析的环节