這篇文章給大家分享的是有關(guān)JMM如何保證共享變量訪問的可見性的內(nèi)容。小編覺得挺實(shí)用的,因此分享給大家做個(gè)參考,一起跟隨小編過來看看吧。
創(chuàng)新互聯(lián)主要從事成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)東寶,十年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18982081108
前言
JMM是內(nèi)存模型規(guī)范在Java語言中的體現(xiàn)。JMM保證了在多核CPU多線程編程環(huán)境下,對(duì)共享變量讀寫的原子性、可見性和有序性。
什么是可見性問題
我們從一段簡單的代碼來看看到底什么是可見性問題。
public class VolatileDemo { boolean started = false; public void startSystem(){ System.out.println(Thread.currentThread().getName()+" begin to start system, time:"+System.currentTimeMillis()); started = true; System.out.println(Thread.currentThread().getName()+" success to start system, time:"+System.currentTimeMillis()); } public void checkStartes(){ if (started){ System.out.println("system is running, time:"+System.currentTimeMillis()); }else { System.out.println("system is not running, time:"+System.currentTimeMillis()); } } public static void main(String[] args) { VolatileDemo demo = new VolatileDemo(); Thread startThread = new Thread(new Runnable() { @Override public void run() { demo.startSystem(); } }); startThread.setName("start-Thread"); Thread checkThread = new Thread(new Runnable() { @Override public void run() { while (true){ demo.checkStartes(); } } }); checkThread.setName("check-Thread"); startThread.start(); checkThread.start(); } }
上面的列子中,一個(gè)線程來改變started的狀態(tài),另外一個(gè)線程不停地來檢測started的狀態(tài),如果是true就輸出系統(tǒng)啟動(dòng),如果是false就輸出系統(tǒng)未啟動(dòng)。那么當(dāng)start-Thread線程將狀態(tài)改成true后,check-Thread線程在執(zhí)行時(shí)是否能立即“看到”這個(gè)變化呢?答案是不一定能立即看到。這邊我做了很多測試,大多數(shù)情況下是能“感知”到started這個(gè)變量的變化的。但是偶爾會(huì)存在感知不到的情況。請(qǐng)看下下面日志記錄:
start-Thread begin to start system, time:1577079553515 start-Thread success to start system, time:1577079553516 system is not running, time:1577079553516 ==>此處start-Thread線程已經(jīng)將狀態(tài)設(shè)置成true,但是check-Thread線程還是沒檢測到 system is running, time:1577079553516 system is running, time:1577079553516 system is running, time:1577079553516 system is running, time:1577079553516 system is running, time:1577079553516 system is running, time:1577079553516 system is running, time:1577079553517 system is running, time:1577079553517 system is running, time:1577079553517 system is running, time:1577079553517 system is running, time:1577079553517 system is running, time:1577079553517 system is running, time:1577079553517 system is running, time:1577079553519 system is running, time:1577079553519 system is running, time:1577079553519 system is running, time:1577079553519 system is running, time:1577079553519 system is running, time:1577079553519 system is running, time:1577079553519 system is running, time:1577079553519 system is running, time:1577079553519
上面的現(xiàn)象可能會(huì)讓人比較困惑,為什么有時(shí)候check-Thread線程能感知到狀態(tài)的變化,有時(shí)候又感知不到變化呢?這個(gè)現(xiàn)象就是在多核CPU多線程編程環(huán)境下會(huì)出現(xiàn)的可見性問題。
Java內(nèi)存模型規(guī)定了所有的變量都存儲(chǔ)在主內(nèi)存中,每條線程還有自己的工作內(nèi)存,線程在工作內(nèi)存中保存的值是主內(nèi)存中值的副本,線程對(duì)變量的所有操作都必須在工作內(nèi)存中進(jìn)行,而不能直接讀寫主內(nèi)存。等到線程對(duì)變量操作完畢之后會(huì)將變量的最新值刷新回到主內(nèi)存。
但是何時(shí)刷新這個(gè)最新值又是隨機(jī)的。所以就有可能一個(gè)線程已經(jīng)將一個(gè)共享變量更新了,但是還沒刷新回主內(nèi)存,那么這時(shí)其他對(duì)這個(gè)變量進(jìn)行讀寫的線程就看不到這個(gè)最新值。這個(gè)就是多CPU多線程編程環(huán)境下的可見性問題。也是上面代碼會(huì)出現(xiàn)問題的原因。
JMM對(duì)可見性問題的保證
在多CPU多線程編程環(huán)境下,對(duì)共享變量的讀寫會(huì)出現(xiàn)可見性問題。但是幸好JMM提供了相應(yīng)的技術(shù)手段來幫我們規(guī)避這些問題,可以讓程序正確運(yùn)行。JMM針對(duì)可見性問題,主要提供了如下手段:
volatile關(guān)鍵字
synchronized關(guān)鍵字
Lock鎖
CAS操作(原子操作類)
volatile關(guān)鍵字
使用volatile關(guān)鍵字修飾一個(gè)變量可以保證變量的可見性。所以對(duì)于上面的代碼,我們只需要簡單的修改下代碼就可以讓程序正確運(yùn)行了。
private volatile boolean started = false;
使用volatile修飾一個(gè)共享變量可以達(dá)到如下的效果:
一旦線程對(duì)這個(gè)共享變量的副本做了修改,會(huì)立馬刷新最新值到主內(nèi)存中去;
一旦線程對(duì)這個(gè)共享變量的副本做了修改,其他線程中對(duì)這個(gè)共享變量拷貝的副本值會(huì)失效,其他線程如果需要對(duì)這個(gè)共享變量進(jìn)行讀寫,必須重新從主內(nèi)存中加載。
那么volatile具體是怎么達(dá)到上面兩個(gè)效果的呢?其實(shí)volatile底層使用的是內(nèi)存屏障來保證可見性的。
內(nèi)存屏障(英語:Memory barrier),也稱內(nèi)存柵欄,內(nèi)存柵障,屏障指令等,是一類同步屏障指令,是CPU或編譯器在對(duì)內(nèi)存隨機(jī)訪問的操作中的一個(gè)同步點(diǎn),使得此點(diǎn)之前的所有讀寫操作都執(zhí)行后才可以開始執(zhí)行此點(diǎn)之后的操作。大多數(shù)現(xiàn)代計(jì)算機(jī)為了提高性能而采取亂序執(zhí)行,這使得內(nèi)存屏障成為必須。
語義上,內(nèi)存屏障之前的所有寫操作都要寫入內(nèi)存;內(nèi)存屏障之后的讀操作都可以獲得同步屏障之前的寫操作的結(jié)果。因此,對(duì)于敏感的程序塊,寫操作之后、讀操作之前可以插入內(nèi)存屏障。
對(duì)內(nèi)存屏障做下簡單的總結(jié):
內(nèi)存屏障是一個(gè)指令級(jí)別的同步點(diǎn);
內(nèi)存屏障之前的寫操作都必須立馬刷新回主內(nèi)存;
內(nèi)存屏障之后的讀操作都必須從主內(nèi)存中讀取最新值;
在有內(nèi)存屏障的地方,會(huì)禁止指令重排序,即屏障下面的代碼不能跟屏障上面的代碼交換執(zhí)行順序,即在執(zhí)行到內(nèi)存屏障這句指令時(shí),在它前面的操作已經(jīng)全部完成。
synchronized關(guān)鍵字
使用synchronized代碼塊或者synchronized方法也可以保證共享變量的可見性。只要如下修改上面的代碼,我們就能得到正確的執(zhí)行結(jié)果。
public synchronized void startSystem(){ System.out.println(Thread.currentThread().getName()+" begin to start system, time:"+System.currentTimeMillis()); value = 2; started = true; System.out.println(Thread.currentThread().getName()+" success to start system, time:"+System.currentTimeMillis()); } public synchronized void checkStartes(){ if (started){ System.out.println("system is running, time:"+System.currentTimeMillis()); }else { System.out.println("system is not running, time:"+System.currentTimeMillis()); } }
當(dāng)線程釋放鎖時(shí),JMM會(huì)把該線程對(duì)應(yīng)的本地內(nèi)存中的共享變量刷新到主內(nèi)存中。當(dāng)線程獲取鎖時(shí),JMM會(huì)把該線程對(duì)應(yīng)的本地內(nèi)存置為無效。從而使得被監(jiān)視器保護(hù)的臨界區(qū)代碼必須從主內(nèi)存中讀取共享變量。我們發(fā)現(xiàn)鎖具有和volatile一致的內(nèi)存語義,所以使用synchronized也可以實(shí)現(xiàn)共享變量的可見性。
Lock接口
使用Lock相關(guān)的實(shí)現(xiàn)類也可以保證共享變量的可見性。其實(shí)現(xiàn)原理和synchronized的實(shí)現(xiàn)原理類似,這邊也就不再贅述了。
CAS機(jī)制(Atomic類)
使用原子操作類也可以保證共享變量操作的可見性。所以我們只要如下修稿上面的代碼就行了。
private AtomicBoolean started = new AtomicBoolean(false);
原子操作類底層使用的是CAS機(jī)制。Java中CAS機(jī)制每次都會(huì)從主內(nèi)存中獲取最新值進(jìn)行compare,比較一致之后才會(huì)將新值set到主內(nèi)存中去。而且這個(gè)整個(gè)操作是一個(gè)原子操作。所以CAS操作每次拿到的都是主內(nèi)存中的最新值,每次set的值也會(huì)立即寫到主內(nèi)存中。
感謝各位的閱讀!關(guān)于“JMM如何保證共享變量訪問的可見性”這篇文章就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,讓大家可以學(xué)到更多知識(shí),如果覺得文章不錯(cuò),可以把它分享出去讓更多的人看到吧!