LongAdder 的理解与使用场景

Doug lea 在jdk注释中写了这样一段话来解释：
该类在多线程更新一个公共的sum(该sum收集统计信息)比AtomicLong 更加高效，而不是应用于细粒度的并发控制。在少量的并发下AtomicLong 与LongAdder 具有相似的性能，但是大量并发下LongAdder更加优秀，但是需要更多的内存。
具体使用场景：假设我们使用CurrentHashMap 来统计string 的频率 由于频率值可能会被并发修改 所以可以考虑使用LongAdder.
该类继承自Number但是并没有定义equals 和hashcode 方法，因为该类设计初衷是实例不可变的，并且也不是被用作集合的key.

LongAdder 高效的原因是减少了乐观锁的重试次数。

LongAdder 继承了Striped64类，该类就有Cell[] cells 字段，以及base字段，base字段在cells 为空的时候进行的cas尝试add,或者在cas初始化或者扩容的时候进行cas进行add。Cell 类有一个value 属性以及cas设置value属性的方法。
longAdder 正是因为将cas 的对象分离到各个cell中 这样才提高了并发。Striped64有这样一个变量NCPU 代表着cells 长度 如果现在已经大于等于 NCPU,那么就不会在进行扩容了。原因是NCPU代表机器真正的并发能力，最多可能就只有这么多的线程同时工作。

逻辑：对于add操作 一开始我们当然希望直接对base add,如果cas base 失败 或者目前已经cells数组已经初始化过了那么就可能进行longAccumulate();当然也是有条件的：如果cells未初始化 或者已初始化但是对应的cell为null 或者对应的cell cas add的过程发生了竞争，那么都需要进行longAccumulate(long x,LongBinaryOperator fn,boolean wasUnContended);来进行累加操作。