建站
咨詢
售后
建站咨詢
新聞中心
?問(wèn)題
Java并發(fā)情況下總是會(huì)遇到各種意向不到的問(wèn)題，比如下面的代碼：
int num = 0;
boolean ready = false;
// 線程1 執(zhí)行此方法
public void actor1(I_Result r) {
if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}
// 線程2 執(zhí)行此方法
public void actor2(I_Result r) {
num = 2;
ready = true;
}
- 線程1中如果發(fā)現(xiàn)ready=true?,那么r1的值等于num + num?，否則等于1，然后將結(jié)果保存到I_Result對(duì)象中
- 線程2中先修改num=2?,然后設(shè)置ready=true
那大家覺得I_Result?中的r1值可能是多少呢？
- r1值等于4， 這個(gè)大家都能想到, CPU先執(zhí)行了線程2，然后執(zhí)行線程1
- r1值等于1，這個(gè)也容易理解，CPU先執(zhí)行了線程1，然后執(zhí)行線程2
- 那我如果說(shuō)r1值有可能等于0，大家可能覺得離譜，不信的話，我們驗(yàn)證下。
壓測(cè)驗(yàn)證結(jié)果
由于并發(fā)問(wèn)題出現(xiàn)的概率比較低，我們可以使用openjdk?提供的jcstress框架進(jìn)行壓測(cè)，就能夠出現(xiàn)各種可能的情況。
jcstress：全名The Java Concurrency Stress tests，是一個(gè)實(shí)驗(yàn)工具和一套測(cè)試工具，用于幫助研究JVM、類庫(kù)和硬件中并發(fā)支持的正確性。詳細(xì)使用可以參考文章：https://www.cnblogs.com/wwjj4811/p/14310930.html
1.生成壓測(cè)工程
mvn archetype:generate -DinteractiveMode=false -DarchetypeGroupId=org.openjdk.jcstress -DarchetypeArtifactId=jcstress-java-test-archetype -DarchetypeVersion=0.5 -DgroupId=com.alvin -DartifactId=juc-order -Dversion=1.0
生成的工程代碼如下圖：
2.填充測(cè)試內(nèi)容
- 方法actor1?是壓測(cè)第一個(gè)線程干的活，將結(jié)果保存到I_Result中。
- 方法actor2是壓測(cè)第二個(gè)線程干的活
- 類前面的@Outcome?注解用來(lái)展示驗(yàn)證結(jié)果，特別是id="0"這個(gè)是我們感興趣的結(jié)果
3.運(yùn)行壓測(cè)工程
mvn clean install java -jar target/jcstress.jar
4.查看運(yùn)行結(jié)果
運(yùn)行結(jié)果如下圖所示：
- 有4000多次出現(xiàn)了0的結(jié)果
- 大部分情況的結(jié)果還是1和4
你是不是還是很困惑，其實(shí)這就是并發(fā)執(zhí)行的一些坑，我們下面來(lái)解釋下原因。
原因分析
如果先要出現(xiàn)r1的值等于0?，那么有一個(gè)可能0+0=0?，那么也就是num=0。
你可能想num怎么可能等于0，代碼邏輯明明是先設(shè)置num=2?,然后才修改ready=true?, 最后才會(huì)走到num+num 的邏輯啊....
在并發(fā)的世界里，我們千萬(wàn)不要被固有的思維限制了，那是不是有可能num=2和ready=true的執(zhí)行順序發(fā)生了變化呢。如果你想到這里，也基本接近真相了。
原因： JAVA中在指令不存在依賴的情況下，會(huì)進(jìn)行順序的調(diào)整，這種現(xiàn)象叫做指令重排序，是 JIT 編譯器在運(yùn)行時(shí)的一些優(yōu)化。這也是為什么出現(xiàn)0的根本原因。
指令重排不會(huì)影響單線程執(zhí)行的結(jié)果，但是在多線程的情況下，會(huì)有個(gè)可能出現(xiàn)問(wèn)題。
理解指令重排序
前面提到出現(xiàn)問(wèn)題的原因是因?yàn)橹噶钪嘏判?，你可能還是不大理解指令重排序究竟是什么，以及它的作用，那我這邊用一個(gè)魚罐頭的故事帶大家理解下。
我們可以把工人當(dāng)做CPU，魚當(dāng)做指令，工人加工一條魚需要 50 分鐘，如果一條魚、一條魚順序加工，這樣是不是比較慢？
沒辦法得優(yōu)化下，不然要喝西北風(fēng)了，發(fā)現(xiàn)每個(gè)魚罐頭的加工流程有 5 個(gè)步驟：
- 去鱗清洗 10分鐘
- 蒸煮瀝水 10分鐘
- 加注湯料 10分鐘
- 殺菌出鍋 10分鐘
- 真空封罐 10分鐘
每個(gè)步驟中也是用到不同的工具，那能否可以并行呢？如下圖所示：
我們發(fā)現(xiàn)中間用很多步驟是并行做的，大大的提高了效率。但是在并行加工魚的過(guò)程中，就會(huì)出現(xiàn)順序的調(diào)整，比如先做第二條的魚的某個(gè)步驟，然后在做第一條魚的步驟。
現(xiàn)代 CPU 支持多級(jí)指令流水線，幾乎所有的馮?諾伊曼型計(jì)算機(jī)的 CPU，其工作都可以分為 5 個(gè)階段：取指令、指令譯碼、執(zhí)行指令、訪存取數(shù)和結(jié)果寫回，可以稱之為五級(jí)指令流水線。CPU 可以在一個(gè)時(shí)鐘周期內(nèi)，同時(shí)運(yùn)行五條指令的不同階段（每個(gè)線程不同的階段），本質(zhì)上流水線技術(shù)并不能縮短單條指令的執(zhí)行時(shí)間，但變相地提高了指令地吞吐率。
處理器在進(jìn)行重排序時(shí)，必須要考慮指令之間的數(shù)據(jù)依賴性
單線程環(huán)境也存在指令重排，由于存在依賴性，最終執(zhí)行結(jié)果和代碼順序的結(jié)果一致
多線程環(huán)境中線程交替執(zhí)行，由于編譯器優(yōu)化重排，會(huì)獲取其他線程處在不同階段的指令同時(shí)執(zhí)行
volatile關(guān)鍵字
那么對(duì)于上面的問(wèn)題，如何解決呢？
使用volatile關(guān)鍵字。
volatile? 的底層實(shí)現(xiàn)原理是內(nèi)存屏障，Memory Barrier（Memory Fence）
- 對(duì)volatile 變量的寫指令后會(huì)加入寫屏障
- 對(duì)volatile 變量的讀指令前會(huì)加入讀屏障
內(nèi)存屏障本質(zhì)上是一個(gè)CPU指令，形象點(diǎn)理解就是一個(gè)柵欄，攔在那里，無(wú)法跨越。
內(nèi)存屏障分為寫屏障和讀屏障，有什么有呢？
1.保證可見性
- 寫屏障保證在該屏障之前的，對(duì)共享變量的改動(dòng)，都同步到主存當(dāng)中
- 讀屏障保證在該屏障之后，對(duì)共享變量的讀取，加載的是主存中最新數(shù)據(jù)
2.保證有序性
寫屏障會(huì)確保指令重排序時(shí)，不會(huì)將寫屏障之前的代碼排在寫屏障之后
讀屏障會(huì)確保指令重排序時(shí)，不會(huì)將讀屏障之后的代碼排在讀屏障之前
回到前面的問(wèn)題，如果對(duì)ready?加了volatile以后，那么num=2就無(wú)法到后面去了，同樣讀取也是，如上圖所示。
final底層也是通過(guò)內(nèi)存屏障實(shí)現(xiàn)的，它與volatile一樣。
- 對(duì)final變量的寫指令加入寫屏障。也就是類初始化的賦值的時(shí)候會(huì)加上寫屏障。
- 對(duì)final變量的讀指令加入讀屏障。加載內(nèi)存中final變量的最新值。
總結(jié)
JAVA并發(fā)中的有序性問(wèn)題其實(shí)比較難理解，本文通過(guò)一個(gè)例子驗(yàn)證了并發(fā)情況下會(huì)出現(xiàn)有序性的問(wèn)題，從而引發(fā)意想不到的結(jié)果。這個(gè)主要的原因是為了提高性能，指令會(huì)發(fā)生重排序?qū)е碌?。為了解決這樣的問(wèn)題，我們可以使用volatile這個(gè)關(guān)鍵字修飾變量，它能夠保證有序性和可見性，但是無(wú)法保證原子性。如果以后遇到一些成員變量或者靜態(tài)變量就要特別注意了，需要分析并發(fā)情況下會(huì)有哪些問(wèn)題。
分享標(biāo)題：深刻理解Java并發(fā)中的有序性問(wèn)題和解決之道
轉(zhuǎn)載源于：http://www.5511xx.com/article/dhscsco.html
