并发程序三大要素
原标题:并发程序三大要素
主题:并发编程三大要素
目标:用例子讲解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··················
相关文章
-
大港油田信息中心“精英讲师团”亮相数智油田系列培训班
-
共享充电宝代理有什么优势?
-
杀死盗版的新逻辑
-
刘晓庆参投的P2P理想宝清盘,13亿待还可债转房、债转股票
-
股价暴涨20%,净利润涨超6成,特步三年转型做对了什么?
-
《重返帝国》的极致画面水平从何而来
-
碾压模式下,直播之后再无风口
-
德国教授:看不懂中国人,为什么中国人从来都不提自己的成就
-
华为与美国政府打官司,但输赢或许不是最重要的
-
经营30多家天猫店,双11销售18亿,卖身5年后它终于赎回了自己
-
ppt怎么制作红包抽拉式抽奖动画效果,抽拉式效果
-
一群大佬猛肝30天,最后就做出个13kb的游戏?
-
买手机不知道怎么选,先看看销量
-
“超级IP季”200天赋能300IP:网易新闻的内容差异化解题新思路
-
唱好“先分期后开卡”的信用卡新模式是妄想狂欢
-
人工智能正在学习管理人类:未来会统治人类世界吗?
-
最强CNN语音识别算法开源了:词错率5%,训练超快,Facebook出品
-
微信显示“正在输入”,其实不是在回你消息,背后原因挺“伤人”
-
315后多家电商APP下架“电子烟”关键词,京东今日恢复搜索结果丨钛快讯
-
李鬼代理频现,OTT广告市场乱象何时休?
-
腾讯视频:将支持用户选集解锁
-
唏嘘,国内知名浏览器宣布停更!还涉及这些产品
-
宇宙中心成长三角?五道口第一个不服!
-
在线阅读变革时间已至,米读、连尚免费读书、飞读等谁主沉浮
-
新初一七年级上册单词表,快收藏起来!暑假做好预习
-
产品经理的瓶颈期,如何破局?
-
夸夸群的火爆皆有来处,下一代圈子社交产品在哪里?
-
荣耀8X系列出货量破千万的启示:品质够硬核才可能赢得用户
-
西安做小程序开发该如何入手,有没有什么好的方法或者简单的操作