引言

前一阵子看ConcurrentHashMap的源码，其中计数部分提及到LongAdder，之后看了一下LongAdder，发现他们实现的思路是一样的，都是将单节点的并发分散到多个节点。
LongAdder的使用场景也就适用于高并发的情形。比如QPS的计算，在多个线程频发更新QPS的时候，效率会很高。
计数选型：
单线程那直接用Long最好了，并发不高的情况用AtomicLong，并发高时选LongAdder。

AtomicLong，并发都作用到了单一的volatile的value上。

1
private volatile long value;

而LongAdder将并发分散到了多个Cell上，增加实现比较复杂，但是在高并发场景确实比较优秀。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
/**
  * Padded variant of AtomicLong supporting only raw accesses plus CAS.
  *
  * JVM intrinsics note: It would be possible to use a release-only
  * form of CAS here, if it were provided.
  */
 @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 mechanics
     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);
         }
     }
 }

 /** Number of CPUS, to place bound on table size */
 static final int NCPU = Runtime.getRuntime().availableProcessors();

 /**
  * Table of cells. When non-null, size is a power of 2.
  */
 transient volatile Cell[] cells;

LongAdder将竞争数据按照线程的粒度进行分离，相比所有竞争线程对一个共享变量使用CAS不断尝试在性能上要效率多了，这也是为什么在高并发环境下LongAdder要优于AtomicLong的原因。