并发程序三大要素
原标题:并发程序三大要素
主题:并发编程三大要素
目标:用例子讲解3要素;刻意练习:细致完整
目标读者:需要了解并发知识的人
并发编程三大要素
并发即多个线程同时运行。所谓一个和尚挑水喝,两个和尚抬水喝,三个和尚没水喝。做事的人一多,就容易出幺蛾子,程序也不例外。所以,为了保证最后结果的正确性,需要保证下面的三大要素。
可见性(visibility)
一个线程对共享变量进行修改,另外的线程能立马看到
先看下面一个小例子:
public class Code3 {private static /*volatile*/ int num = 0;
public static void main(String[] args) throws InterruptedException {
System.out.println("程序执行");
new Thread(() -> {
System.out.println("子线程开始");
while (num == 0) {
// System.out.println(num);
}
System.out.println("子线程结束");
}).start();
TimeUnit.SECONDS.sleep(1);
num = 1;
}
}
上面程序的执行结果是:
“子线程结束”一直没有输出出来,意味着,对于子线程来说num一直都是等于0的,循环一直没有结束。但我们在主线程,也就是main方法里明明把num改成1了呀。为什么会这样呢?
这是因为线程在执行的时候会读取出一份共享变量的拷贝到线程本地的缓存中,所以线程们对这个变量的修改,互相之间是不可见的。
解决这个问题的一个办法,就是给变量加上volatile关键字,这个关键字的作用之一,就是保证变量的更新,对所有的线程都是可见的。
我在第9行注释掉的那句打印,也可以解决可见性的问题,因为println()方法里加了synchronized,它也能变量的可见性。
有序性(ordering)
程序执行的顺序和代码的顺序保持一致
程序在实际的执行过程中,不一定是严格按照代码的顺序执行的。
为了提高效率,可能会发生指令重排。
比如,有两句话
- 等待用户输入变量y的值
- 计算x+1
因为CPU的执行速度很快,在等待语句1执行的过程中,我可以先把语句2给算出来。而不是空在那里等着,因为两句话没什么前后关联。
当然,如果两句话换成了
- 等待用户输入变量x的值
- 计算x+1
这就肯定不能重排了。
所以,对于单线程来说,就有一个特性叫as if serial,像是顺序执行一样。只要保证单线程结果的最终一致性就可以了。
但,对于多线程来说就可能出现问题。比如下面这个程序。
public class Code3 {private static int num = 0;
private static volatile boolean flag = true;
public static void main(String[] args) throws InterruptedException {
System.out.println("程序执行");
new Thread(() -> {
System.out.println("子线程开始");
while (flag) {
}
System.out.println(num);
}).start();
TimeUnit.SECONDS.sleep(1);
num = 1;
flag = false;
}
}
因为15行和16行可能出现重排的现象,flag=false先执行,再执行num=1,就可能导致最终11行子线程输出的num值为0,而不是1。
当然这个做实验做很多次也不一定能做得出来,只是有可能发生。
解决这个问题已经可以使用volatile关键字,volatile的另一个作用就是禁止重排序。
具体的实现机制是增加内存屏障(Memory Barrier)
- LoadLoadBarrier,load1;屏障;load2,即屏障的前后都是读指令,则load2必须等待load1执行完毕。
- StoreStoreBarrier,store1;屏障;store2,即屏障的前后都是写指令,则store2必须等待store1执行完毕。
- LoadStoreBarrier,load;屏障;store,即屏障的前是读指令,屏障后是写指令,则store必须等待load执行完毕。
- StoreLoadBarrier,store;屏障;load,即屏障的前是写指令,屏障后是读指令,则load必须等待store执行完毕。
- 写屏障(即volatile写之前都不能写,volatile写之后才可以读) StoreStoreBarrier volatile写(store) StoreLoadBarrier
- 读屏障(即volatile读之后,才可以读写) volatile读(load) LoadLoadBarrier LoadStoreBarrire
原子性(atomicity)
不可分割的操作,要么都成功,要么都失败
还是先来一段小代码:
public class Code3 {private static volatile int num = 0;
public static void main(String[] args) throws InterruptedException {
Thread[] threads = new Thread[100];
CountDownLatch countDownLatch = new CountDownLatch(threads.length);
for (int i = 0; i < threads.length; i++) {
threads[i] = new Thread(() -> {
for (int j = 0; j < 100; j++) {
num++;
}
countDownLatch.countDown();
});
}
for (Thread thread : threads) {
thread.start();
}
countDownLatch.await();
System.out.println(num);
}
}
起100个线程,同时对num这个变量做100次自增操作,理想的结果应该是100*100=10000。但我的机器上测试,实际的结果是9000多。
说明一个什么问题呢,就是自增这个操作不是原子性的,因为它可能中间过程被打断。
假设自增有三步:
- 把num值取出来
- 把num值加一
- 把num值放回去
就可能出现,当前num=0,线程1把0取出来了,并且完成了加一,把值变成了1,这时候线程2也来了,它取出来的也是0,并且把值从0改成1,并且把1的值写了回去。然后这时候线程1开始执行第3步,又一次把1写了回去。这就导致了数据不一致的结果。如果自增操作不可打算的话,两个线程执行完的结果应该是2,而不是1。
解决这个问题的办法,就是上锁。
上锁的本质:让并发的程序序列化,即把原本同时执行的程序,改成前后顺序执行。
悲观锁
认为这个操作一定会被打断,所以不管三七二十一,先锁上再说。通过synchronized实现。(第10行)
public class Code3 {private static volatile int num = 0;
public static void main(String[] args) throws InterruptedException {
Thread[] threads = new Thread[100];
CountDownLatch countDownLatch = new CountDownLatch(threads.length);
for (int i = 0; i < threads.length; i++) {
threads[i] = new Thread(() -> {
for (int j = 0; j < 100; j++) {
synchronized (Code3.class) {
num++;
}
}
countDownLatch.countDown();
});
}
for (Thread thread : threads) {
thread.start();
}
countDownLatch.await();
System.out.println(num);
}
}
乐观锁
认为这个操作不会被打断,所以先不上锁,在写入的时候验证原数据是否被修改,如果被修改了,就读取新的值,再重试一遍,直到成功为止。通过CAS(Compare And Swap/Set)实现。
java自带有CAS方式的整形类AtomicInteger。
public class Code3 {private static AtomicInteger num = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Thread[] threads = new Thread[100];
CountDownLatch countDownLatch = new CountDownLatch(threads.length);
for (int i = 0; i < threads.length; i++) {
threads[i] = new Thread(() -> {
for (int j = 0; j < 100; j++) {
num.incrementAndGet();
}
countDownLatch.countDown();
});
}
for (Thread thread : threads) {
thread.start();
}
countDownLatch.await();
System.out.println(num);
}
}
锁类型的选择
并不是乐观锁看着名字比较积极就无脑选择乐观锁比较好。
因为乐观锁会一直频繁的重试,直到成功为止,这个重试的过程也是会消耗cpu资源的。
而悲观锁通过等待队列的方式实现,在等待锁的过程中不消耗资源,所以可以视情况而定。
如果锁内部执行的时间较长,且排队人数很多,就可以选择悲观锁。
如果锁内部执行时间很多,且排队人数不多,就可以选择乐观锁。
字数:不统计
耗时:2小时45分
··················END··················
相关文章
-
阿里云上盒马狂奔
-
快讯|打造信息安全生态,在线教育集团iTutorGroup上线安全应急响应中心
-
工业互联网解决方案创新应用报告(2020)附下载
-
STARTTLS相关漏洞影响多个邮件客户端
-
你应该知道的直播间带货话术技巧
-
比94年一遇的故宫元宵夜场,还要有看头:用游戏造座紫禁城
-
业界第一的苹果走下神坛:被万亿市值蒙蔽了双眼
-
【虎嗅早报】百度回应“抄袭天猫精灵”:无稽之谈,有独立设计;酷狗音乐等1048款APP超范围收集用户信息
-
在阿里巴巴有个流水线,专门生产“平头吴彦祖”和“简约辛芷蕾”
-
科学家最新预言!300年后的人类是这样的,太震撼了
-
dwg格式用什么软件打开
-
京东2018年Q4营收超预期但这些隐患不能忽视
-
腾讯将严打微信跑分,《流浪地球》辟谣授权手游
-
直播平台纷纷进军在线教育虎牙到底有哪些优势?
-
全国流量免费领取,联通用户赶紧薅羊毛,官方漏洞随时修复
-
凭借技术创新和生态繁荣,创维能终止彩电市场的价格战吗?
-
三星S10系列爆卖涨幅超60%挤进前三
-
成人电影涌向众筹网站,色情和互联网的关系正在发生变化
-
扎克伯格下场怼人1场直播蒸发425亿,Facebook为何都在惧怕这个中国男人
-
这4个产品新人写PRD、竞品分析容易遇到的问题,你能解决吗?
-
QQ大更新,新功能真香!你会放弃微信改用QQ吗?
-
越是没本事的男人,越会发这5种动态,中的越多越“掉价”!
-
终于!年度账单又来了!网友:看完emo了
-
马云第一次判断失误,投资百亿却无人问津,如今面临倒闭危机
-
微信怎样注意隐私安全
-
315曝光“探针盒子”的背后藏着大数据应用场景的恶劣生态!
-
贾跃亭内部邮件曝光,网友:恒大要的还是土地,老贾还是要面子
-
退休倒计时!马云又悄悄干了2件事,网友:大佬,收下我的膝盖!
-
国内和境外游戏版号申报正式重启;特斯拉缩减董事会成员;每日优鲜App炒作996遭差评轰炸