Java并发计数器的深入理解

前言

一提到线程安全的并发计数器，atomiclong 必然是第一个被联想到的工具。atomic* 一系列的原子类以及它们背后的 cas 无锁算法，常常是高性能，高并发的代名词。本文将会阐释，在并发场景下，使用 atomiclong 来充当并发计数器将会是一个糟糕的设计，实际上存在不少 atomiclong 之外的计数器方案。近期我研究了一些 jdk1.8 以及 jctools 的优化方案，并将它们的对比与实现细节整理于此。

阅读本文前

本文相关的基准测试代码均可在博主的 github 中找到，测试方式全部采用 jmh，这篇文章可以帮助你入门 jmh。

atomiclong 的前世今生

在 java 中，atomic* 是高效的，这得益于 sun.misc.unsafe 提供的一系列底层 api，使得 java 这样的高级语言能够直接和硬件层面的 cpu 指令打交道。并且在 jdk1.7 中，这样的底层指令可以配合 cas 操作，达到 lock-free。

在 jdk1.7 中，atomiclong 的关键代码如下：

public final long getandincrement() {
 while (true) {
 long current = get();
 long next = current + 1;
 if (compareandset(current, next))
  return current;
 }
}

public final boolean compareandset(long expect, long update) {
 return unsafe.compareandswaplong(this, valueoffset, expect, update);
}

1. get() 方法 volatile 读当前 long 值
2. 自增
3. 自旋判断新值与当前值
4. 自旋成功，返回；否则返回 1

我们特别留意到 jdk1.7 中 unsafe 使用的方法是 compareandswaplong，它与 x86 cpu 上的 lock cmpxchg 指令对应，并且在应用层使用 while(true) 完成自旋，这个细节在 jdk1.8 中发生了变化。

在 jdk1.8 中，atomiclong 的关键代码如下：

public final long getandincrement() {
 return unsafe.getandaddlong(this, valueoffset, 1l);
}

jdk1.7 的 cas 操作已经不复存在了，转而使用了 getandaddlong 方法，它与 x86 cpu 上的 lock xadd 指令对应，以原子方式返回当前值并递增（fetch and add）。

当问及 atomic* 高效的原因，回答 cas 是不够全面且不够严谨的，jdk1.7 的 unsafe.compareandswaplong 以及 jdk1.8 的 unsafe.getandaddlong 才是关键，且 jdk1.8 中不存在 cas。

jdk1.8 atomiclong 相比 jdk1.7 atomiclong 的表现是要优秀的，这点我们将在后续的测评中见证。

atomiclong 真的高效吗？

无论在 jdk1.7 还是 jdk1.8 中，atomic* 的开销都是很大的，主要体现在：

1. 高并发下，cas 操作可能会频繁失败，真正更新成功的线程占少数。(jdk1.7 独有的问题)
2. 我之前的文章中介绍过“伪共享” (false sharing) 问题，但在 cas 中，问题则表现的更为直接，这是“真共享”，与”伪共享“存在相同的问题：缓存行失效，缓存一致性开销变大。
3. 底层指令的开销不见得很低，无论是 lock xadd 还是 lock cmpxchg，想深究的朋友可以参考 instruction_tables ，（这一点可能有点钻牛角尖，但不失为一个角度去分析高并发下可行的优化）
4. atomic* 所做的，比我们的诉求可能更大，有时候我们只需要计数器具备线程安全地递增这样的特性，但 atomic* 的相关操作每一次都伴随着值的返回。他是个带返回值的方法，而不是 void 方法，而多做了活大概率意味着额外的开销。

抛开上述导致 atomiclong 慢的原因，atomiclong 仍然具备优势：

1. 上述的第 4 点换一个角度也是 atomiclong 的有点，相比下面要介绍的其他计数器方案，atomiclong 能够保证每次操作都精确的返回真实的递增值。你可以借助 atomiclong 来做并发场景下的递增序列号方案，注意，本文主要讨论的是计数器方案，而不是序列号方案。
2. 实现简单，回到那句话：“简单的架构通常性能不高，高性能的架构通常复杂度很高”，atomiclong 属于性能相对较高，但实现极其简单的那种方案，因为大部分的复杂性，由 jmm 和 jni 方法屏蔽了。相比下面要介绍的其他计数器实现，atomiclong 真的太“简易”了。

看一组 atomiclong 在不同并发量下的性能表现：

横向对比，写的性能相比读的性能要差很多，在 20 个线程下写性能比读性能差距了 4~5 倍。

纵向对比，主要关注并发写，线程竞争激烈的情况下，单次自增耗时从 22 ns 增长为了 488 ns，有明显的性能下降。

实际场景中，我们需要统计系统的 qps、接口调用次数，都需要使用到计数的功能，写才是关键，并不是每时每刻都需要关注自增后的返回值，而 atomiclong 恰恰在核心的写性能上有所欠缺。由此引出其他计数器方案。

认识 longadder

doug lea 在 jdk1.8 中找到了一个上述问题的解决方案，他实现了一个 longadder 类。

@since 1.8
@author doug lea
public class longadder extends striped64 implements serializable {}

longadder 的 api 如下

longadder

你应当发现，longadder 和 atomiclong 明显的区别在于，increment 是一个 void 方法。直接来看看 longadder 的性能表现如何。(la = longadder, al = atomiclong, 单位 ns/op)：

我们从中可以发现一些有意思的现象，网上不少很多文章没有从读写上对比二者，直接宣称 longadder 性能优于 atomiclong，其实不太严谨。在单线程下，并发问题没有暴露，两者没有体现出差距；随着并发量加大，longadder 的 increment 操作更加优秀，而 atomiclong 的 get 操作则更加优秀。鉴于在计数器场景下的特点—写多读少，所以写性能更高的 longadder 更加适合。

longadder 写速度快的背后

网上分析 longadder 源码的文章并不少，我不打算详细分析源码，而是挑选了一些必要的细节以及多数文章没有提及但我认为值得分析的内容。

1、cell 设计减少并发修改时的冲突

longadder

在 longadder 的父类 striped64 中存在一个 volatile cell[] cells; 数组，其长度是 2 的幂次方，每个 cell 都填充了一个 @contended 的 long 字段，为了避免伪共享问题。

@sun.misc.contended static final class cell {
 volatile long value;
 cell(long x) { value = x; }
 // ... ignore
}

longadder 通过一系列算法，将计数结果分散在了多个 cell 中，cell 会随着并发量升高时发生扩容，最坏情况下 cell == cpu core 的数量。cell 也是 longadder 高效的关键，它将计数的总值分散在了各个 cell 中，例如 5 = 3 + 2，下一刻，某个线程完成了 3 + (2 + 1) = 6 的操作，而不是在 5 的基础上完成直接相加操作。通过 longadder 的 sum() 方法可以直观的感受到这一点（longadder 不存在 get 方法）

public long sum() {
 cell[] as = cells; cell a;
 long sum = base;
 if (as != null) {
 for (int i = 0; i < as.length; ++i) {
  if ((a = as[i]) != null)
  sum += a.value;
 }
 }
 return sum;
}

这种惰性求值的思想，在 concurrenthashmap 中的 size() 中也存在，毕竟他们的作者都是 doug lea。

2、并发场景下高效获取随机数

longadder 内部算法需要获取随机数，而 random 类在并发场景下也是可以优化的。

threadlocalrandom random = threadlocalrandom.current();
random.nextint(5);

使用 threadlocalrandom 替代 random，同样出现在了 longadder 的代码中。

3、longaccumulate

longaccumulate 方法是 longadder 的核心方法，内部存在大量的分支判断。首先和 jdk1.7 的 atomiclong 一样，它使用的是 unsafe.compareandswaplong 来完成自旋，不同之处在于，其在初次 cas 方式失败的情况下(说明多个线程同时想更新这个值)，尝试将这个值分隔成多个 cell，让这些竞争的线程只负责更新自己所属的 cell，这样将竞争压力分散开。

longadder 的前世今生

其实在 jdk1.7 时代，longadder 还未诞生时，就有一些人想着自己去实现一个高性能的计数器了，比如一款 java 性能监控框架 dropwizard/metrics 就做了这样事，在早期版本中，其优化手段并没有 jdk1.8 的 longadder 丰富，而在 metrics 的最新版本中，其已经使用 jdk1.8 的 longadder 替换掉了自己的*。在最后的测评中，我们将 metrics 版本的 longadder 也作为一个参考对象。

jctools 中的 concurrentautotable

并非只有 longadder 考虑到了并发场景下计数器的优化，大名鼎鼎的并发容器框架 jctool 中也提供了和今天主题相关的实现，虽然其名称和 counter 看似没有关系，但通过其 java 文档和 api ，可以发现其设计意图考虑到了计数器的场景。

an auto-resizing table of longs, supporting low-contention cas operations.updates are done with cas's to no particular table element.the intent is to support highly scalable counters , r/w locks, and other structures where the updates are associative, loss-free (no-brainer), and otherwise happen at such a high volume that the cache contention for cas'ing a single word is unacceptable.

concurrentautotable

在最后的测评中，我们将 jctools 的 concurrentautotable 也作为一个参考对象。

最终测评

jdk1.7 的 atomiclong，jdk1.8 的 atomiclong，jdk 1.8 的 longadder，metrics 的 longadder，jctools 的 concurrentautotable，我对这五种类型的计数器使用 jmh 进行基准测试。

public interface counter {
 void inc();
 long get();
}

将 5 个类都适配成 counter 接口的实现类，采用 @state(scope.group)，@group 将各组测试用例进行隔离，尽可能地排除了互相之间的干扰，由于计数器场景的特性，我安排了 20 个线程进行并发写，1 个线程与之前的写线程共存，进行并发读。mode=avgt 代表测试的是方法的耗时，越低代表性能越高。

benchmark                      (countertype)  mode  cnt     score       error  units
counterbenchmark.rw                  atomic7  avgt    3  1049.906 ±  2146.838  ns/op
counterbenchmark.rw:get              atomic7  avgt    3   143.352 ±   125.388  ns/op
counterbenchmark.rw:inc              atomic7  avgt    3  1095.234 ±  2247.913  ns/op
counterbenchmark.rw                  atomic8  avgt    3   441.837 ±   364.270  ns/op
counterbenchmark.rw:get              atomic8  avgt    3   149.817 ±    66.134  ns/op
counterbenchmark.rw:inc              atomic8  avgt    3   456.438 ±   384.646  ns/op
counterbenchmark.rw      concurrentautotable  avgt    3   144.490 ±   577.390  ns/op
counterbenchmark.rw:get  concurrentautotable  avgt    3  1243.494 ± 14313.764  ns/op
counterbenchmark.rw:inc  concurrentautotable  avgt    3    89.540 ±   166.375  ns/op
counterbenchmark.rw         longaddermetrics  avgt    3   105.736 ±   114.330  ns/op
counterbenchmark.rw:get     longaddermetrics  avgt    3   313.087 ±   307.381  ns/op
counterbenchmark.rw:inc     longaddermetrics  avgt    3    95.369 ±   132.379  ns/op
counterbenchmark.rw               longadder8  avgt    3    98.338 ±    80.112  ns/op
counterbenchmark.rw:get           longadder8  avgt    3   274.169 ±   113.247  ns/op
counterbenchmark.rw:inc           longadder8  avgt    3    89.547 ±    78.720  ns/op

如果我们只关注 inc 即写性能，可以发现 jdk1.8 的 longadder 表现的最为优秀，concurrentautotable 以及两个版本的 longadder 在一个数量级之上；1.8 的 atomiclong 相比 1.7 的 atomiclong 优秀很多，可以得出这样的结论，1.7 的 cas+lock cmpxchg 方案的确不如 1.8 的 lock xadd 来的优秀，但如果与特地优化过的其他计数器方案来进行比较，便相形见绌了。

如果关注 get 性能，虽然这意义不大，但可以见得，atomiclong 的 get 性能在高并发下表现依旧优秀，而 longadder 组合求值的特性，导致其性能必然存在一定下降，位列第二梯队，而 concurrentautotable 的并发读性能最差。

关注整体性能，counterbenchmark.rw 是对一组场景的整合打分，可以发现，在我们模拟的高并发计数器场景下，1.8 的 longadder 获得整体最低的延迟 98 ns，相比性能最差的 jdk1.7 atomiclong 实现，高了整整 10 倍有余，并且，随着并发度提升，这个数值还会增大。

atomiclong 可以被废弃吗？

既然 longadder 的性能高出 atomiclong 这么多，我们还有理由使用 atomiclong 吗？

本文重点讨论的角度还是比较局限的：单机场景下并发计数器的高效实现。atomiclong 依然在很多场景下有其存在的价值，例如一个内存中的序列号生成器，atomiclong 可以满足每次递增之后都精准的返回其递增值，而 longadder 并不具备这样的特性。longadder 为了性能而丧失了一部分功能，这体现了计算机的哲学，无处不在的 trade off。

高性能计数器总结

atomiclong ：并发场景下读性能优秀，写性能急剧下降，不适合作为高性能的计数器方案。内存需求量少。

longadder ：并发场景下写性能优秀，读性能由于组合求值的原因，不如直接读值的方案，但由于计数器场景写多读少的缘故，整体性能在几个方案中最优，是高性能计数器的首选方案。由于 cells 数组以及缓存行填充的缘故，占用内存较大。

concurrentautotable ：拥有和 longadder 相近的写入性能，读性能则更加不如 longadder。它的使用需要引入 jctools 依赖，相比 jdk 自带的 longadder 并没有优势。但额外说明一点，concurrentautotable 的使用并非局限于计数器场景，其仍然存在很大的价值。

在前面提到的性能监控框架 metrics，以及著名的熔断框架 hystrix 中，都存在 longadder 的使用场景，有兴趣的朋友快去实践一下 longadder 吧。

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对的支持。