juca：LongAdder

Posted 2020-12-28 redreampt

LongAdder是什么？

很多人根本连API文档都没有好好读，就喜欢吵着“JUC大法好，底层实现妙妙妙”，然后就钻入低层实现的分析了，浮躁是搞技术的大忌。

LongAdder的类文档说明如下：

一个或多个变量一起来维持一个初始为0的long类型的和。当更新(add())跨线程竞争时，
变量集合可能会动态增长以减少竞争。方法sum()(或者，等效地，value())返回维持sum的变量之间的当前和。

当多个线程更新用于收集统计信息等目的的公共和时，而不是细粒度同步控制，这个类通常比AtomicLong更好。
在更新竞争较低的情况下，这两个类具有相似的特性。但是在高竞争情况下，这一类的预期吞吐量明显更高，代价是更高的空间消耗。

LongAdder可以与ConcurrentHashMap一起使用，以维护可伸缩的frequency map(histogram或multiset的形式)。
例如，要将计数添加到ConcurrentHashMap<String,LongAdder> freqs中，初始化(如果尚未存在)，可以使用freqs.computeIfAbsent(k -> new LongAdder()).increment();

这个类扩展了Number，但没有定义equals、hashCode和comparTo等方法，因为实例预计会发生突变，因此不能用作集合键。

从它的接口 API来看，也完全在一个adder的责任范围内。

（接口API 略）

因此，我们来回答heading中的问题：什么是LongAdder？

可以看到文档对该类的功能和缺陷说得明明白白。无论它底层实现多么复杂，多么精妙，该类本质是构建在经典的并发计数器模型¹上的并发计数器。经典并发计数器模型就是将计数器拆分为多个局部计数器和一个全局计数器，多个局部计数器可以有效的减少竞争情况，全局计数器用于对数据进行汇总。

它的缺点也很明显：由于设计者对其定位，没有覆盖equals,hashCode方法(Object)，没有实现Comparable接口，因此不能用作集合键。

与AtomicLong比较

//待续

实现思想

//待续

---

1. 《OS-TEP》29 并发数据结构--29.1并发计数器?