查看原文
其他

高并发下的 AtomicLong 性能有点差!

占小狼 占小狼的博客 2019-05-05

如果让你实现一个计数器,有点经验的同学可以很快的想到使用AtomicInteger或者AtomicLong进行简单的封装。

因为计数器操作涉及到内存的可见性和线程之间的竞争,而Atomic*的实现完美的屏蔽了这些技术细节,我们只需要执行相应的方法,就能实现对应的业务需求。

Atomic**虽然好用,不过这些的操作在并发量很大的情况下,性能问题也会被相应的放大。我们可以先看下其中 getAndIncrement的实现代码

  1. public final long getAndIncrement() {

  2. return unsafe.getAndAddLong(this, valueOffset, 1L);

  3. }


  4. // unsafe类中的实现

  5. public final long getAndAddLong(Object var1, long var2, long var4) {

  6. long var6;

  7. do {

  8. var6 = this.getLongVolatile(var1, var2);

  9. } while(!this.compareAndSwapLong(var1, var2, var6, var6 + var4));


  10. return var6;

  11. }

很显然,在 getAndAddLong实现中,为了实现正确的累加操作,如果并发量很大的话,cpu会花费大量的时间在试错上面,相当于一个spin的操作。如果并发量小的情况,这些消耗可以忽略不计。

既然已经意识到Atomic*有这样的缺陷,Doug Lea大神又给我们提供了LongAdder,内部的实现有点类似ConcurrentHashMap的分段锁,最好的情况下,每个线程都有独立的计数器,这样可以大量减少并发操作。

下面通过JMH比较一下AtomicLong 和 LongAdder的性能。

  1. @OutputTimeUnit(TimeUnit.MICROSECONDS)

  2. @BenchmarkMode(Mode.Throughput)

  3. public class Main {


  4. private static AtomicLong count = new AtomicLong();

  5. private static LongAdder longAdder = new LongAdder();

  6. public static void main(String[] args) throws Exception {

  7. Options options = new OptionsBuilder().include(Main.class.getName()).forks(1).build();

  8. new Runner(options).run();

  9. }


  10. @Benchmark

  11. @Threads(10)

  12. public void run0(){

  13. count.getAndIncrement();

  14. }


  15. @Benchmark

  16. @Threads(10)

  17. public void run1(){

  18. longAdder.increment();

  19. }

  20. }

1、设置BenchmarkMode为Mode.Throughput,测试吞吐量 2、设置BenchmarkMode为Mode.AverageTime,测试平均耗时

线程数为1

1、吞吐量

  1. Benchmark Mode Cnt Score Error Units

  2. Main.run0 thrpt 5 154.525 ± 9.767 ops/us

  3. Main.run1 thrpt 5 89.599 ± 7.951 ops/us

2、平均耗时

  1. Benchmark Mode Cnt Score Error Units

  2. Main.run0 avgt 5 0.007 ± 0.001 us/op

  3. Main.run1 avgt 5 0.011 ± 0.001 us/op

单线程情况下: 1、AtomicLong的吞吐量和平均耗时都占优势

线程数为10

1、吞吐量

  1. Benchmark Mode Cnt Score Error Units

  2. Main.run0 thrpt 5 37.780 ± 1.891 ops/us

  3. Main.run1 thrpt 5 464.927 ± 143.207 ops/us

2、平均耗时

  1. Benchmark Mode Cnt Score Error Units

  2. Main.run0 avgt 5 0.290 ± 0.038 us/op

  3. Main.run1 avgt 5 0.021 ± 0.001 us/op

并发线程为10个时:

  • LongAdder的吞吐量比较大,是AtomicLong的10倍多。

  • LongAdder的平均耗时是AtomicLong的十分之一。

线程数为30

1、吞吐量

  1. Benchmark Mode Cnt Score Error Units

  2. Main.run0 thrpt 5 36.215 ± 2.341 ops/us

  3. Main.run1 thrpt 5 486.630 ± 26.894 ops/us

2、平均耗时

  1. Main.run0 avgt 5 0.792 ± 0.021 us/op

  2. Main.run1 avgt 5 0.063 ± 0.002 us/op

线程数为30个时:

  • LongAdder的吞吐量比较大,也是AtomicLong的10倍多。

  • LongAdder的平均耗时也是AtomicLong的十分之一。

总结

一些高并发的场景,比如限流计数器,建议使用LongAdder替换AtomicLong,性能可以提升不少。



分享一份蛮不错的《Java核心知识点整理.pdf》,覆盖了JVM、锁、高并发、反射、Spring原理、微服务、Zookeeper、数据库、数据结构等等。


获取方式:关注公众号并回复 666 领取,更多内容陆续奉上,敬请期待。


 近期热文:


    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存