1. 程式人生 > >【死磕Java併發】--Java記憶體模型之happens-before

【死磕Java併發】--Java記憶體模型之happens-before

在上篇部落格(【死磕Java併發】—–深入分析volatile的實現原理)LZ提到過由於存線上程本地記憶體和主記憶體的原因,再加上重排序,會導致多執行緒環境下存在可見性的問題。那麼我們正確使用同步、鎖的情況下,執行緒A修改了變數a何時對執行緒B可見?

我們無法就所有場景來規定某個執行緒修改的變數何時對其他執行緒可見,但是我們可以指定某些規則,這規則就是happens-before,從JDK 5 開始,JMM就使用happens-before的概念來闡述多執行緒之間的記憶體可見性。

在JMM中,如果一個操作執行的結果需要對另一個操作可見,那麼這兩個操作之間必須存在happens-before關係。

happens-before原則非常重要,它是判斷資料是否存在競爭、執行緒是否安全的主要依據,依靠這個原則,我們解決在併發環境下兩操作之間是否可能存在衝突的所有問題。下面我們就一個簡單的例子稍微瞭解下happens-before ;

1i = 1;       //執行緒A執行j = i ;      //執行緒B執行

j 是否等於1呢?假定執行緒A的操作(i = 1)happens-before執行緒B的操作(j = i),那麼可以確定執行緒B執行後j = 1 一定成立,如果他們不存在happens-before原則,那麼j = 1 不一定成立。這就是happens-before原則的威力。

happens-before原則定義如下:

1. 如果一個操作happens-before另一個操作,那麼第一個操作的執行結果將對第二個操作可見,而且第一個操作的執行順序排在第二個操作之前。 
2. 兩個操作之間存在happens-before關係,並不意味著一定要按照happens-before原則制定的順序來執行。如果重排序之後的執行結果與按照happens-before關係來執行的結果一致,那麼這種重排序並不非法。

下面是happens-before原則規則:

  1. 程式次序規則:一個執行緒內,按照程式碼順序,書寫在前面的操作先行發生於書寫在後面的操作;
  2. 鎖定規則:一個unLock操作先行發生於後面對同一個鎖額lock操作;
  3. volatile變數規則:對一個變數的寫操作先行發生於後面對這個變數的讀操作;
  4. 傳遞規則:如果操作A先行發生於操作B,而操作B又先行發生於操作C,則可以得出操作A先行發生於操作C;
  5. 執行緒啟動規則:Thread物件的start()方法先行發生於此執行緒的每個一個動作;
  6. 執行緒中斷規則:對執行緒interrupt()方法的呼叫先行發生於被中斷執行緒的程式碼檢測到中斷事件的發生;
  7. 執行緒終結規則:執行緒中所有的操作都先行發生於執行緒的終止檢測,我們可以通過Thread.join()方法結束、Thread.isAlive()的返回值手段檢測到執行緒已經終止執行;
  8. 物件終結規則:一個物件的初始化完成先行發生於他的finalize()方法的開始;

我們來詳細看看上面每條規則(摘自《深入理解Java虛擬機器第12章》):

程式次序規則:一段程式碼在單執行緒中執行的結果是有序的。注意是執行結果,因為虛擬機器、處理器會對指令進行重排序(重排序後面會詳細介紹)。雖然重排序了,但是並不會影響程式的執行結果,所以程式最終執行的結果與順序執行的結果是一致的。故而這個規則只對單執行緒有效,在多執行緒環境下無法保證正確性。

鎖定規則:這個規則比較好理解,無論是在單執行緒環境還是多執行緒環境,一個鎖處於被鎖定狀態,那麼必須先執行unlock操作後面才能進行lock操作。

volatile變數規則:這是一條比較重要的規則,它標誌著volatile保證了執行緒可見性。通俗點講就是如果一個執行緒先去寫一個volatile變數,然後一個執行緒去讀這個變數,那麼這個寫操作一定是happens-before讀操作的。

傳遞規則:提現了happens-before原則具有傳遞性,即A happens-before B , B happens-before C,那麼A happens-before C

執行緒啟動規則:假定執行緒A在執行過程中,通過執行ThreadB.start()來啟動執行緒B,那麼執行緒A對共享變數的修改在接下來執行緒B開始執行後確保對執行緒B可見。

執行緒終結規則:假定執行緒A在執行的過程中,通過制定ThreadB.join()等待執行緒B終止,那麼執行緒B在終止之前對共享變數的修改線上程A等待返回後可見。

上面八條是原生Java滿足Happens-before關係的規則,但是我們可以對他們進行推匯出其他滿足happens-before的規則:

  1. 將一個元素放入一個執行緒安全的佇列的操作Happens-Before從佇列中取出這個元素的操作
  2. 將一個元素放入一個執行緒安全容器的操作Happens-Before從容器中取出這個元素的操作
  3. 在CountDownLatch上的倒數操作Happens-Before CountDownLatch#await()操作
  4. 釋放Semaphore許可的操作Happens-Before獲得許可操作
  5. Future表示的任務的所有操作Happens-Before Future#get()操作
  6. 向Executor提交一個Runnable或Callable的操作Happens-Before任務開始執行操作

這裡再說一遍happens-before的概念:如果兩個操作不存在上述(前面8條 + 後面6條)任一一個happens-before規則,那麼這兩個操作就沒有順序的保障,JVM可以對這兩個操作進行重排序。如果操作A happens-before操作B,那麼操作A在記憶體上所做的操作對操作B都是可見的。

下面就用一個簡單的例子來描述下happens-before原則:

1private int i = 0;public void write(int j ){    i = j;}public int read(){    return i;}

我們約定執行緒A執行write(),執行緒B執行read(),且執行緒A優先於執行緒B執行,那麼執行緒B獲得結果是什麼?;我們就這段簡單的程式碼一次分析happens-before的規則(規則5、6、7、8 + 推導的6條可以忽略,因為他們和這段程式碼毫無關係):

  1. 由於兩個方法是由不同的執行緒呼叫,所以肯定不滿足程式次序規則;
  2. 兩個方法都沒有使用鎖,所以不滿足鎖定規則;
  3. 變數i不是用volatile修飾的,所以volatile變數規則不滿足;
  4. 傳遞規則肯定不滿足;

所以我們無法通過happens-before原則推匯出執行緒A happens-before執行緒B,雖然可以確認在時間上執行緒A優先於執行緒B指定,但是就是無法確認執行緒B獲得的結果是什麼,所以這段程式碼不是執行緒安全的。那麼怎麼修復這段程式碼呢?滿足規則2、3任一即可。

happen-before原則是JMM中非常重要的原則,它是判斷資料是否存在競爭、執行緒是否安全的主要依據,保證了多執行緒環境下的可見性。

下圖是happens-before與JMM的關係圖(摘自《Java併發程式設計的藝術》)

happens-before

相關推薦

Java併發-----Java記憶體模型happens-before

在上篇部落格(【死磕Java併發】—–深入分析volatile的實現原理)LZ提到過由於存線上程本地記憶體和主記憶體的原因,再加上重排序,會導致多執行緒環境下存在可見性的問題。那麼我們正確使用同步、鎖的情況下,執行緒A修改了變數a何時對執行緒B可見? 我們無法就所有場景來規

Java併發--Java記憶體模型happens-before

在上篇部落格(【死磕Java併發】—–深入分析volatile的實現原理)LZ提到過由於存線上程本地記憶體和主記憶體的原因,再加上重排序,會導致多執行緒環境下存在可見性的問題。那麼我們正確使用同步、鎖的情況下,執行緒A修改了變數a何時對執行緒B可見?我們無法就所有場景來規定某

Java 併發Java 記憶體模型 happens-before

原文: 微信公眾號  程式設計師大咖            裡面各種好文章,大讚 來源:chenssy, cmsblogs.com/?p=2102 那麼我們正確使用同步、鎖的情況下,執行緒A修改了變數a何時對執行緒B可見? 我們無法就所有場景來規定某個執

Java 記憶體模型 happens-before

  那麼我們正確使用同步、鎖的情況下,執行緒A修改了變數a何時對執行緒B可見?   我們無法就所有場景來規定某個執行緒修改的變數何時對其他執行緒可見,但是我們可以指定某些規則,這規則就是happens-before,從JDK 5 開始,JMM就使用happens-befor

Java併發-----Java記憶體模型分析volatile

volatile可見性;對一個volatile的讀,總可以看到對這個變數最終的寫; volatile原子性;volatile對單個讀/寫具有原子性(32位Long、Double),但是複合操作除外,例如i++; JVM底層採用“記憶體屏障”來實現volat

Java併發-----Java記憶體模型總結

經過四篇部落格闡述,我相信各位對Java記憶體模型有了最基本認識了,下面LZ就做一個比較簡單的總結。 總結 JMM規定了執行緒的工作記憶體和主記憶體的互動關係,以及執行緒之間的可見性和程式的執行順序。一方面,要為程式設計師提供足夠強的記憶體可見性保證;另

Java併發-----J.U.CAQS:阻塞和喚醒執行緒

此篇部落格所有原始碼均來自JDK 1.8 線上程獲取同步狀態時如果獲取失敗,則加入CLH同步佇列,通過通過自旋的方式不斷獲取同步狀態,但是在自旋的過程中則需要判斷當前執行緒是否需要阻塞,其主要方法在acquireQueued(): if (sho

Java併發-----J.U.C阻塞佇列:ArrayBlockingQueue

ArrayBlockingQueue,一個由陣列實現的有界阻塞佇列。該佇列採用FIFO的原則對元素進行排序新增的。 ArrayBlockingQueue為有界且固定,其大小在構造時由建構函式來決定,確認之後就不能再改變了。ArrayBlockingQueu

Java併發—– J.U.C併發工具類:Semaphore

此篇部落格所有原始碼均來自JDK 1.8訊號量Semaphore是一個控制訪問多個共享資源的計數

Java併發—– J.U.CAQS:同步狀態的獲取與釋放

此篇部落格所有原始碼均來自JDK 1.8在前面提到過,AQS是構建Java同步元件的基礎,我們期

Java併發-----J.U.C併發工具類:Exchanger

此篇部落格所有原始碼均來自JDK 1.8 前面三篇部落格分別介紹了CyclicBarrier、CountDownLatch、Semaphore,現在介紹併發工具類中的最後一個Exchange。Exchange是最簡單的也是最複雜的,簡單在於API非常簡

Java併發-----J.U.CCondition

此篇部落格所有原始碼均來自JDK 1.8 在沒有Lock之前,我們使用synchronized來控制同步,配合Object的wait()、notify()系列方法可以實現等待/通知模式。在Java SE5後,Java提供了Lock介面,相對於Synch

Java併發-----J.U.C重入鎖:ReentrantLock

此篇部落格所有原始碼均來自JDK 1.8 ReentrantLock,可重入鎖,是一種遞迴無阻塞的同步機制。它可以等同於synchronized的使用,但是ReentrantLock提供了比synchronized更強大、靈活的鎖機制,可以減少死鎖發生

Java併發-----J.U.C阻塞佇列:DelayQueue

DelayQueue是一個支援延時獲取元素的無界阻塞佇列。裡面的元素全部都是“可延期”的元素,列頭的元素是最先“到期”的元素,如果佇列裡面沒有元素到期,是不能從列頭獲取元素的,哪怕有元素也不行。也就是說只有在延遲期到時才能夠從佇列中取元素。 DelayQu

Java併發-----J.U.C併發工具類:CyclicBarrier

此篇部落格所有原始碼均來自JDK 1.8 CyclicBarrier,一個同步輔助類,在API中是這麼介紹的: 它允許一組執行緒互相等待,直到到達某個公共屏障點 (common barrier point)。在涉及一組固定大小的執行緒的程式中,這些執

Java併發—–J.U.CAQS(一篇就夠了)

作者:大明哥  原文地址:http://cmsblogs.com 越是核心的東西越是要反覆看,本文篇幅較長,希望各位細細品讀,來回多讀幾遍理解下。 AQS簡介 java的內建鎖一直都是備受爭議的,在JDK 1.6之前,synchronized這個重量級鎖其效能一直都

Java併發-----J.U.CAQS:AQS簡介

Java的內建鎖一直都是備受爭議的,在JDK 1.6之前,synchronized這個重量級鎖其效能一直都是較為低下,雖然在1.6後,進行大量的鎖優化策略(【死磕Java併發】—–深入分析synchronized的實現原理),但是與Lock相比synchroni

Java併發-----J.U.CAQS:CLH同步佇列

此篇部落格所有原始碼均來自JDK 1.8 CLH同步佇列是一個FIFO雙向佇列,AQS依賴它來完成同步狀態的管理,當前執行緒如果獲取同步狀態失敗時,AQS則會將當前執行緒已經等待狀態等資訊構造成一個節點(Node)並將其加入到CLH同步佇列,同時會

Java併發Java中的原子操作

Java中的原子操作 原子更新基本型別 原子更新陣列 原子更新引用型別 原子更新欄位類 參考 原子更新基本型別 一個生動的例子 public class AtomicIntegerExample { privat

Java併發Java中的執行緒池

Java中的執行緒池 執行流程 執行緒池的建立 提交任務 關閉執行緒池 參考 執行流程 處理流程如下: execute()方法執行示意圖如下: 執行緒池的建立 corePoolSize:執行緒池