只有光头才能变强
之前已经写过多线程相关的文章了,有兴趣的同学可以去了解一下:
在阅读《阿里巴巴 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++
需要经过读取-修改-写入
三个步骤。举个例子:
count++
,此时count的值为11count++
,此时count的值也是11(因为线程b读到的count是10)要将上面的代码变成线程安全的(每次得出的结果是100),那也很简单,毕竟我们是学过synchronized锁的人:
increase()
加synchronized锁就好了public synchronized void increase() { count++; }
无论执行多少次,得出的都是100:
从上面的代码我们也可以发现,只做一个++
这么简单的操作,都用到了synchronized锁,未免有点小题大做了。
于是我们原子变量的类就登场了!
在写文章之前,本以为对cas有一定的了解了(因为之前已经看过相关概念,以为自己理解了)..但真正敲起键盘写的时候,还是发现没完全弄懂...所以再来看看cas吧。
来源维基百科:
比较并交换(compare and swap, cas),是原子操作的一种,可用于在多线程编程中实现不被打断的数据交换操作,从而避免多线程同时改写某一数据时由于执行顺序不确定性以及中断的不可预知性产生的数据不一致问题。 该操作通过将内存中的值与指定数据进行比较,当数值一样时将内存中的数据替换为新的值。
cas有3个操作数:
当多个线程尝试使用cas同时更新同一个变量时,只有其中一个线程能更新变量的值(a和内存值v相同时,将内存值v修改为b),而其它线程都失败,失败的线程并不会被挂起,而是被告知这次竞争中失败,并可以再次尝试(或者什么都不做)。
我们画张图来理解一下:
我们可以发现cas有两种情况:
我们再继续往下看,如果内存值v和我们的预期值a不相等时,应该什么时候重试,什么时候什么都不做。
比如说,我上面用了100个线程,对count值进行加1。我们都知道:如果在线程安全的情况下,这个count值最终的结果一定是为100的。那就意味着:每个线程都会对这个count值实质地进行加1。
我继续画张图来说明一下cas是如何重试(循环再试)的:
上面图只模拟出两个线程的情况,但足够说明问题了。
上面是每个线程都要为count值加1,但我们也可以有这种情况:将count值设置为5
我也来画个图说明一下:
理解cas的核心就是:cas是原子性的,虽然你可能看到比较后再修改(compare and swap)觉得会有两个操作,但终究是原子性的!
原子变量类在java.util.concurrent.atomic
包下,总体来看有这么多个:
我们可以对其进行分类:
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指令,不会被打断。
既然我们上面也说到了,使用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,基本就会用了(网上也写得比较详细,所以我这里果断偷懒了)...
使用cas有个缺点就是aba的问题,什么是aba问题呢?首先我用文字描述一下:
count=10
,现在有三个线程,分别为a、b、c上面的操作都可以正常执行完的,这样会发生什么问题呢??线程c无法得知线程a和线程b修改过的count值,这样是有风险的。
下面我再画个图来说明一下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的问题了。
如果是 jdk8,推荐使用 longadder 对象,比 atomiclong 性能更好(减少乐观锁的重试次数)。
去查阅了一些博客和资料,大概的意思就是:
参考资料:
参考资料:
如果你觉得我写得还不错,了解一下:
如对本文有疑问, 点击进行留言回复!!
[杭电多校2020]第一场 1004 Distinct Sub-palindromes
Swift -- 将本地生成的UIImage进行持久化保存(存到文件中fileManager.createFile)
网友评论