atomiclong 初始化_【J.U.C】LongAdder与AtomicLong

前一阵子看ConcurrentHashMap的源码，其中计数部分提及到LongAdder，之后看了一下LongAdder，发现他们实现的思路是一样的，都是将单节点的并发分散到多个节点。

LongAdder的使用场景也就适用于高并发的情形。比如QPS的计算，在多个线程频发更新QPS的时候，效率会很高。

计数选型：

单线程那直接用Long最好了，并发不高的情况用AtomicLong，并发高时选LongAdder。

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

private volatile long value;

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

/**

* 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的原因。