其他系列文章导航
Java基础合集
数据结构与算法合集设计模式合集
多线程合集
分布式合集
ES合集
其他系列文章导航
文章目录
前言
一、CAS
1.1 CAS 全称
1.2 通俗理解CAS
1.3 CAS的问题
1.4 解决 ABA 问题
二、LongAdder
2.1 什么是 LongAdder
2.2 为什么推荐推荐 LongAdder
三、AtomicLong
3.1 什么是 AtomicLong
3.2 为什么不推荐 AtomicLong
四、总结
在分布式系统中,计数器是一个常见的需求。为了实现高并发、高可用的计数器,我们需要选择一个合适的实现方式。
在 Java 中,有两种常见的计数器实现方式:AtomicLong 和 LongAdder。
最近,阿里巴巴在一份技术报告中推荐使用 LongAdder ,而不是 AtomicLong 。
本文将介绍这两种计数器的原理和优缺点,并分析为什么阿里巴巴推荐使用 LongAdder 。
全称:compare and swap,比较并交换。
虽然翻译过来是[比较并交换],但它是一个原子性的操作,对应到CPU指令为 cmpxchg 。
CAS有个缺点就是会带来 ABA 的问题。
从CAS更新的时候,我们可以发现它只比对当前值和内存值是否相等,这会带来个问题,下面我举例说明下:
要解决ABA的问题,Java 也提供了 AtomicStampedReference 类供我们用,说白了就是加了个版本,比对的就是内存值+版本是否一致。
疑问:
为什么阿里巴巴开发手册提及到推荐使用 LongAdder 对象,比AtomicLong 性能更好(减少乐观锁的重试次数)?
原因:
因为 AtomicLong 做累加的时候实际上就是多个线程操作同一个目标资源。
在高并发时,只有一个线程是执行成功的,其他的线程都会失败,不断自旋(重试),自旋会成为瓶颈。
而 LongAdder 的思想就是把要操作的目标资源 分散,到数组 Cell 中。
每个线程对自己的 Cell 变量的 value 进行原子操作,大大降低了失败的次数。
这就是为什么在高并发场景下,推荐使用 LongAdder 的原因。
LongAdder是JDK1.8由Doug Lea大神新增的原子操作类,位于java.util.concurrent.atomic包下,LongAdder在高并发的场景下会比AtomicLong 具有更好的性能,代价是消耗更多的内存空间。
LongAdder是Google开源的一个高性能计数器实现。它采用了一种分段锁的策略,将一个long型的变量分割成多个16字节的段,每个段都使用一个独立的AtomicLong进行更新。这样,在高并发场景下,多个线程可以同时对不同的段进行更新操作,互不干扰。
LongAdder的优点是并发性能高,适用于高并发的场景。由于采用了分段锁的策略,LongAdder可以避免AtomicLong中的竞争问题。此外,LongAdder还支持可扩展性,可以通过增加更多的段来提高性能。但是,LongAdder的缺点是代码相对复杂一些,需要更多的维护成本。
LongAdder设计思想上,采用分段的方式降低并发冲突的概率。通过维护一个基准值base和 Cell 数组:
如下图所示:
AtomicLong是Java提供的一个原子类,用于实现高并发的计数器。它利用了CAS(Compare-and-Swap)操作来保证线程安全。在AtomicLong中,每次计数操作都会先读取当前值,然后使用CAS操作更新值。如果值没有被其他线程修改过,则更新成功,否则需要重新尝试。
AtomicLong的优点是简单易用,性能也不错。但是,在高并发场景下,AtomicLong可能会出现竞争问题。因为多个线程可能同时读取和更新同一个AtomicLong的当前值,导致数据不一致。此外,AtomicLong的CAS操作也可能因为硬件和操作系统的原因出现失败的情况。
在LongAdder之前,当我们在进行计数统计的时,通常会使用AtomicLong来实现。AtomicLong能保证并发情况下计数的准确性,其内部通过CAS来解决并发安全性的问题。
如下图所示:
图里可以看出在高并发情况下,当有大量线程同时去更新一个变量,任意一个时间点只有一个线程能够成功,绝大部分的线程在尝试更新失败后,会通过自旋的方式再次进行尝试,这样严重占用了CPU的时间片,进而导致系统性能问题。
阿里巴巴推荐使用LongAdder的原因主要有以下几点:
总之,阿里巴巴推荐使用LongAdder的原因主要是因为它的高并发性能、可扩展性、代码简单易懂以及更好的适用场景。当然,在实际应用中还需要根据具体场景和需求进行选择和优化。