共计 5436 个字符,预计需要花费 14 分钟才能阅读完成。
前言
只有光头才能变强
之前已经写过多线程相关的文章了,有兴趣的同学可以去了解一下:
https://github.com/ZhongFuCheng3y/3y/blob/master/src/thread.md
在阅读《阿里巴巴 Java 开发手册》读后感时,还有未解决的问题:
如果是 count++ 操作,使用如下类实现: AtomicInteger count = new AtomicInteger(); count.addAndGet(1); 如果是 JDK8,推荐使用 LongAdder 对象,比 AtomicLong 性能更好(减少乐观锁的重试次数)。
之前在学习的时候也看过 AtomicInteger 类很多次了,一直没有去做相关的笔记。现在遇到问题了,于是就过来写写笔记,并希望在学习的过程中解决掉问题。
一、基础铺垫
首先我们来个例子:
public class AtomicMain {
public static void main(String[] args) throws InterruptedException {
ExecutorService service = Executors.newCachedThreadPool();
Count count = new Count();
// 100 个线程对共享变量进行加 1
for (int i = 0; i < 100; i++) {
service.execute(() -> count.increase());
}
// 等待上述的线程执行完
service.shutdown();
service.awaitTermination(1, TimeUnit.DAYS);
System.out.println(“ 公众号:Java3y———“);
System.out.println(count.getCount());
}
}
class Count{
// 共享变量
private Integer count = 0;
public Integer getCount() {
return count;
}
public void increase() {
count++;
}
}
你们猜猜得出的结果是多少?是 100 吗?
多运行几次可以发现:结果是不确定的,可能是 95,也可能是 98,也可能是 100
根据结果我们得知:上面的代码是线程不安全的!如果线程安全的代码,多次执行的结果是一致的!
我们可以发现问题所在:count++ 并不是原子操作。因为 count++ 需要经过读取 - 修改 - 写入三个步骤。举个例子:
如果某一个时刻:线程 A 读到 count 的值是 10,线程 B 读到 count 的值也是 10
线程 A 对 count++,此时 count 的值为 11
线程 B 对 count++,此时 count 的值也是 11(因为线程 B 读到的 count 是 10)
所以到这里应该知道为啥我们的结果是不确定了吧。
要将上面的代码变成线程安全的(每次得出的结果是 100),那也很简单,毕竟我们是学过 synchronized 锁的人:
在 increase()加 synchronized 锁就好了
public synchronized void increase() {
count++;
}
无论执行多少次,得出的都是 100:
从上面的代码我们也可以发现,只做一个 ++ 这么简单的操作,都用到了 synchronized 锁,未免有点小题大做了。
Synchronized 锁是独占的,意味着如果有别的线程在执行,当前线程只能是等待!
于是我们原子变量的类就登场了!
1.2CAS 再来看看
在写文章之前,本以为对 CAS 有一定的了解了(因为之前已经看过相关概念,以为自己理解了).. 但真正敲起键盘写的时候,还是发现没完全弄懂 … 所以再来看看 CAS 吧。
来源维基百科:
比较并交换(compare and swap, CAS),是原子操作的一种,可用于在多线程编程中实现不被打断的数据交换操作,从而避免多线程同时改写某一数据时由于执行顺序不确定性以及中断的不可预知性产生的数据不一致问题。该操作通过将内存中的值与指定数据进行比较,当数值一样时将内存中的数据替换为新的值。
CAS 有 3 个操作数:
内存值 V
旧的预期值 A
要修改的新值 B
当多个线程尝试使用 CAS 同时更新同一个变量时,只有其中一个线程能更新变量的值(A 和内存值 V 相同时,将内存值 V 修改为 B),而其它线程都失败,失败的线程并不会被挂起,而是被告知这次竞争中失败,并可以再次尝试(或者什么都不做)。
我们画张图来理解一下:
我们可以发现 CAS 有两种情况:
如果内存值 V 和我们的预期值 A 相等,则将内存值修改为 B,操作成功!
如果内存值 V 和我们的预期值 A 不相等,一般也有两种情况:
重试(自旋)
什么都不做
我们再继续往下看,如果内存值 V 和我们的预期值 A 不相等时,应该什么时候重试,什么时候什么都不做。
1.2.1CAS 失败重试(自旋)
比如说,我上面用了 100 个线程,对 count 值进行加 1。我们都知道:如果在线程安全的情况下,这个 count 值最终的结果一定是为 100 的。那就意味着:每个线程都会对这个 count 值实质地进行加 1。
我继续画张图来说明一下 CAS 是如何重试 (循环再试) 的:
上面图只模拟出两个线程的情况,但足够说明问题了。
1.2.2CAS 失败什么都不做
上面是每个线程都要为 count 值加 1,但我们也可以有这种情况:将 count 值设置为 5
我也来画个图说明一下:
理解 CAS 的核心就是:CAS 是原子性的,虽然你可能看到比较后再修改 (compare and swap) 觉得会有两个操作,但终究是原子性的!
二、原子变量类简单介绍
原子变量类在 java.util.concurrent.atomic 包下,总体来看有这么多个:
我们可以对其进行分类:
基本类型:
AtomicBoolean:布尔型
AtomicInteger:整型
AtomicLong:长整型
数组:
AtomicIntegerArray:数组里的整型
AtomicLongArray:数组里的长整型
AtomicReferenceArray:数组里的引用类型
引用类型:
AtomicReference:引用类型
AtomicStampedReference:带有版本号的引用类型
AtomicMarkableReference:带有标记位的引用类型
对象的属性:
AtomicIntegerFieldUpdater:对象的属性是整型
AtomicLongFieldUpdater:对象的属性是长整型
AtomicReferenceFieldUpdater:对象的属性是引用类型
JDK8 新增 DoubleAccumulator、LongAccumulator、DoubleAdder、LongAdder
是对 AtomicLong 等类的改进。比如 LongAccumulator 与 LongAdder 在高并发环境下比 AtomicLong 更高效。
Atomic 包里的类基本都是使用 Unsafe 实现的包装类。
Unsafe 里边有几个我们喜欢的方法(CAS):
// 第一和第二个参数代表对象的实例以及地址,第三个参数代表期望值,第四个参数代表更新值
public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);
从原理上概述就是:Atomic 包的类的实现绝大调用 Unsafe 的方法,而 Unsafe 底层实际上是调用 C 代码,C 代码调用汇编,最后生成出一条 CPU 指令 cmpxchg,完成操作。这也就为啥 CAS 是原子性的,因为它是一条 CPU 指令,不会被打断。
2.1 原子变量类使用
既然我们上面也说到了,使用 Synchronized 锁有点小题大作了,我们用原子变量类来改一下:
class Count{
// 共享变量(使用 AtomicInteger 来替代 Synchronized 锁)
private AtomicInteger count = new AtomicInteger(0);
public Integer getCount() {
return count.get();
}
public void increase() {
count.incrementAndGet();
}
}
// Main 方法还是如上
修改完,无论执行多少次,我们的结果永远是 100!
其实 Atomic 包下原子类的使用方式都不会差太多,了解原子类各种类型,看看 API,基本就会用了(网上也写得比较详细,所以我这里果断偷懒了)…
2.2ABA 问题
使用 CAS 有个缺点就是 ABA 的问题,什么是 ABA 问题呢?首先我用文字描述一下:
现在我有一个变量 count=10,现在有三个线程,分别为 A、B、C
线程 A 和线程 C 同时读到 count 变量,所以线程 A 和线程 C 的内存值和预期值都为 10
此时线程 A 使用 CAS 将 count 值修改成 100
修改完后,就在这时,线程 B 进来了,读取得到 count 的值为 100(内存值和预期值都是 100),将 count 值修改成 10
线程 C 拿到执行权,发现内存值是 10,预期值也是 10,将 count 值修改成 11
上面的操作都可以正常执行完的,这样会发生什么问题呢??线程 C 无法得知线程 A 和线程 B 修改过的 count 值,这样是有风险的。
下面我再画个图来说明一下 ABA 的问题(以链表为例):
2.3 解决 ABA 问题
要解决 ABA 的问题,我们可以使用 JDK 给我们提供的 AtomicStampedReference 和 AtomicMarkableReference 类。
AtomicStampedReference:
An {@code AtomicStampedReference} maintains an object referencealong with an integer “stamp”, that can be updated atomically.
简单来说就是在给为这个对象提供了一个版本,并且这个版本如果被修改了,是自动更新的。
原理大概就是:维护了一个 Pair 对象,Pair 对象存储我们的对象引用和一个 stamp 值。每次 CAS 比较的是两个 Pair 对象
// Pair 对象
private static class Pair<T> {
final T reference;
final int stamp;
private Pair(T reference, int stamp) {
this.reference = reference;
this.stamp = stamp;
}
static <T> Pair<T> of(T reference, int stamp) {
return new Pair<T>(reference, stamp);
}
}
private volatile Pair<V> pair;
// 比较的是 Pari 对象
public boolean compareAndSet(V expectedReference,
V newReference,
int expectedStamp,
int newStamp) {
Pair<V> current = pair;
return
expectedReference == current.reference &&
expectedStamp == current.stamp &&
((newReference == current.reference &&
newStamp == current.stamp) ||
casPair(current, Pair.of(newReference, newStamp)));
}
因为多了一个版本号比较,所以就不会存在 ABA 的问题了。
2.4LongAdder 性能比 AtomicLong 要好
如果是 JDK8,推荐使用 LongAdder 对象,比 AtomicLong 性能更好(减少乐观锁的重试次数)。
去查阅了一些博客和资料,大概的意思就是:
使用 AtomicLong 时,在高并发下大量线程会同时去竞争更新同一个原子变量,但是由于同时只有一个线程的 CAS 会成功,所以其他线程会不断尝试自旋尝试 CAS 操作,这会浪费不少的 CPU 资源。
而 LongAdder 可以概括成这样:内部核心数据 value 分离成一个数组(Cell),每个线程访问时, 通过哈希等算法映射到其中一个数字进行计数,而最终的计数结果,则为这个数组的求和累加。
简单来说就是将一个值分散成多个值,在并发的时候就可以分散压力,性能有所提高。
参考资料:
AtomicLong 与 LongAdder 性能对比 https://zhuanlan.zhihu.com/p/45489739
LongAdder 源码详解 https://zhuanlan.zhihu.com/p/38288416
最后
参考资料:
Java 并发编程札记 - 目录 https://blog.csdn.net/panweiwei1994/article/details/78483167
《Java 并发编程实战》
《Java 并发编程的艺术》
如果你觉得我写得还不错,了解一下:
坚持原创的技术公众号:Java3y。回复 1 加入 Java 交流群
文章的目录导航(精美脑图 + 海量视频资源):https://github.com/ZhongFuCheng3y/3y