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);来进行累加操作。