并發(fā)編程的模型

并發(fā)編程需要解決的兩個(gè)問(wèn)題：線程之間如何同步，線程之間如何通信。

線程之間通信：共享內(nèi)存，消息傳遞。

共享內(nèi)存通過(guò)線程之間讀-寫(xiě)程序的公共狀態(tài)進(jìn)行通信。消息傳遞要通過(guò)線程之間主動(dòng)傳遞消息進(jìn)行通信。

線程之間同步：控制不同線程之間操作發(fā)生的相對(duì)順序。

共享內(nèi)存并發(fā)模型中的同步是顯式進(jìn)行的。需要手動(dòng)指明代碼在線程之間如何互斥地執(zhí)行。在消息傳遞的并發(fā)模型里，由于消息的發(fā)送必須在消息的接收之前，因此同步是隱式進(jìn)行的。

Java的并發(fā)采用了共享內(nèi)存模型。線程之間的通信是隱式進(jìn)行的，需要手動(dòng)進(jìn)行控制。

Java內(nèi)存模型

在Java中，實(shí)例域，靜態(tài)域和數(shù)組對(duì)象存儲(chǔ)在堆內(nèi)存中，堆內(nèi)存在內(nèi)存之間共享。局部變量，方法定義參數(shù)和異常處理參數(shù)不會(huì)在內(nèi)存中共享，不存在可見(jiàn)性問(wèn)題，不受內(nèi)存模型的影響。Java線程之間的通信由JMM控制，JMM決定了一個(gè)線程對(duì)共享變量的寫(xiě)入何時(shí)對(duì)另一個(gè)線程可見(jiàn)。抽象來(lái)看就是：線程之間的共享變量存儲(chǔ)在主內(nèi)存中，每個(gè)線程有一個(gè)私有的本地內(nèi)存，本地內(nèi)存中存儲(chǔ)了該線程以讀/寫(xiě)共享變量的副本。

線程A與B通信需要經(jīng)過(guò)兩個(gè)步驟：

首先，線程A把本地內(nèi)存A中更新過(guò)的共享變量刷新到主內(nèi)存中去。

然后，線程B到主內(nèi)存中去讀取線程A之前已更新過(guò)的共享變量。

JMM通過(guò)控制主內(nèi)存與每個(gè)線程的本地內(nèi)存之間的交互來(lái)為程序提供內(nèi)存可見(jiàn)性的保證。

重排序

為了提高程序執(zhí)行時(shí)的效率，編譯器和處理器通常會(huì)對(duì)指令做重排序。

編譯器優(yōu)化的重排序。編譯器在不改變單線程程序語(yǔ)義的前提下，可以重新安排語(yǔ)句的執(zhí)行順序。

指令級(jí)并行的重排序。現(xiàn)代處理器采用了指令級(jí)并行技術(shù)（Instruction-Level Parallelism， ILP）來(lái)將多條指令重疊執(zhí)行。如果不存在數(shù)據(jù)依賴性，處理器可以改變語(yǔ)句對(duì)應(yīng)機(jī)器指令的執(zhí)行順序。

內(nèi)存系統(tǒng)的重排序。由于處理器使用緩存和讀/寫(xiě)緩沖區(qū)，這使得加載和存儲(chǔ)操作看上去可能是在亂序執(zhí)行。

這些重排序都可能會(huì)導(dǎo)致多線程程序出現(xiàn)內(nèi)存可見(jiàn)性問(wèn)題。對(duì)于編譯器，JMM的編譯器重排序規(guī)則會(huì)禁止特定類型的編譯器重排序（不是所有的編譯器重排序都要禁止）。對(duì)于處理器重排序，JMM的處理器重排序規(guī)則會(huì)要求java編譯器在生成指令序列時(shí)，插入特定類型的內(nèi)存屏障（memory barriers，intel稱之為memory fence）指令，通過(guò)內(nèi)存屏障指令來(lái)禁止特定類型的處理器重排序（不是所有的處理器重排序都要禁止）。

JMM通過(guò)禁止特定類型的編譯器重排序和處理器重排序?yàn)槌绦蛱峁┝藘?nèi)存可見(jiàn)性的保障。

處理器重排序和內(nèi)存屏障指令

現(xiàn)代的處理器使用寫(xiě)緩沖區(qū)來(lái)臨時(shí)保存向內(nèi)存寫(xiě)入的數(shù)據(jù)。每個(gè)處理器上的寫(xiě)緩沖區(qū)，僅僅對(duì)它所在的處理器可見(jiàn)。這個(gè)特性會(huì)對(duì)內(nèi)存操作的執(zhí)行順序產(chǎn)生重要的影響：處理器對(duì)內(nèi)存的讀/寫(xiě)操作的執(zhí)行順序，不一定與內(nèi)存實(shí)際發(fā)生的讀/寫(xiě)操作順序一致！如圖：

假設(shè)處理器A和處理器B按程序的順序并行執(zhí)行內(nèi)存訪問(wèn)，最終卻可能得到x = y = 0的結(jié)果。具體的原因如下圖所示：

里處理器A和處理器B可以同時(shí)把共享變量寫(xiě)入自己的寫(xiě)緩沖區(qū)（A1，B1），然后從內(nèi)存中讀取另一個(gè)共享變量（A2，B2），最后才把自己寫(xiě)緩存區(qū)中保存的臟數(shù)據(jù)刷新到內(nèi)存中（A3，B3）。當(dāng)以這種時(shí)序執(zhí)行時(shí)，程序就可以得到x = y = 0的結(jié)果。 從內(nèi)存操作實(shí)際發(fā)生的順序來(lái)看，直到處理器A執(zhí)行A3來(lái)刷新自己的寫(xiě)緩存區(qū)，寫(xiě)操作A1才算真正執(zhí)行了。雖然處理器A執(zhí)行內(nèi)存操作的順序?yàn)?#xff1a;A1->A2，但內(nèi)存操作實(shí)際發(fā)生的順序卻是：A2->A1。此時(shí)，處理器A的內(nèi)存操作順序被重排序了。

為了保證內(nèi)存可見(jiàn)性，java編譯器在生成指令序列的適當(dāng)位置會(huì)插入內(nèi)存屏障指令來(lái)禁止特定類型的處理器重排序。JMM把內(nèi)存屏障指令分為下列四類：

StoreLoad Barriers是一個(gè)“全能型”的屏障，它同時(shí)具有其他三個(gè)屏障的效果。執(zhí)行該屏障開(kāi)銷會(huì)很昂貴，因?yàn)楫?dāng)前處理器通常要把寫(xiě)緩沖區(qū)中的數(shù)據(jù)全部刷新到內(nèi)存中（buffer fully flush）。

happens-before

happens-before概念用來(lái)描述操作之間的內(nèi)存可見(jiàn)性。在JMM中，如果一個(gè)操作執(zhí)行的結(jié)果需要對(duì)另一個(gè)操作可見(jiàn)，那么這兩個(gè)操作之間必須要存在happens-before關(guān)系。這里提到的兩個(gè)操作既可以是在一個(gè)線程之內(nèi)，也可以是在不同線程之間。 與程序員密切相關(guān)的happens-before規(guī)則如下：

• 程序順序規(guī)則：一個(gè)線程中的每個(gè)操作，happens- before 于該線程中的任意后續(xù)操作。
• 監(jiān)視器鎖規(guī)則：對(duì)一個(gè)監(jiān)視器鎖的解鎖，happens- before 于隨后對(duì)這個(gè)監(jiān)視器鎖的加鎖。
• volatile變量規(guī)則：對(duì)一個(gè)volatile域的寫(xiě)，happens- before 于任意后續(xù)對(duì)這個(gè)volatile域的讀。
• 傳遞性：如果A happens- before B，且B happens- before C，那么A happens- before C。

注意，兩個(gè)操作之間具有happens-before關(guān)系，并不意味著前一個(gè)操作必須要在后一個(gè)操作之前執(zhí)行！happens-before僅僅要求前一個(gè)操作（執(zhí)行的結(jié)果）對(duì)后一個(gè)操作可見(jiàn)，且前一個(gè)操作按順序排在第二個(gè)操作之前（the first is visible to and ordered before the second）。

數(shù)據(jù)依賴性

如果兩個(gè)操作訪問(wèn)同一個(gè)變量，且這兩個(gè)操作中有一個(gè)為寫(xiě)操作，此時(shí)這兩個(gè)操作之間就存在數(shù)據(jù)依賴性。數(shù)據(jù)依賴分下列三種類型：

上面三種情況，只要重排序兩個(gè)操作的執(zhí)行順序，程序的執(zhí)行結(jié)果將會(huì)被改變。

前面提到過(guò)，編譯器和處理器可能會(huì)對(duì)操作做重排序。編譯器和處理器在重排序時(shí)，會(huì)遵守?cái)?shù)據(jù)依賴性，編譯器和處理器不會(huì)改變存在數(shù)據(jù)依賴關(guān)系的兩個(gè)操作的執(zhí)行順序。

注意，這里所說(shuō)的數(shù)據(jù)依賴性僅針對(duì)單個(gè)處理器中執(zhí)行的指令序列和單個(gè)線程中執(zhí)行的操作，不同處理器之間和不同線程之間的數(shù)據(jù)依賴性不被編譯器和處理器考慮。

as-if-serial語(yǔ)義

as-if-serial語(yǔ)義的意思指：不管怎么重排序（編譯器和處理器為了提高并行度），（單線程）程序的執(zhí)行結(jié)果不能被改變。編譯器，runtime 和處理器都必須遵守as-if-serial語(yǔ)義。

為了遵守as-if-serial語(yǔ)義，編譯器和處理器不會(huì)對(duì)存在數(shù)據(jù)依賴關(guān)系的操作做重排序，因?yàn)檫@種重排序會(huì)改變執(zhí)行結(jié)果。但是，如果操作之間不存在數(shù)據(jù)依賴關(guān)系，這些操作可能被編譯器和處理器重排序。為了具體說(shuō)明，請(qǐng)看下面計(jì)算圓面積的代碼示例：

double pi = 3.14; //A double r = 1.0; //B double area = pi * r * r; //C 復(fù)制代碼

上面三個(gè)操作的數(shù)據(jù)依賴關(guān)系如下圖所示：

如上圖所示，A和C之間存在數(shù)據(jù)依賴關(guān)系，同時(shí)B和C之間也存在數(shù)據(jù)依賴關(guān)系。因此在最終執(zhí)行的指令序列中，C不能被重排序到A和B的前面（C排到A和B的前面，程序的結(jié)果將會(huì)被改變）。但A和B之間沒(méi)有數(shù)據(jù)依賴關(guān)系，編譯器和處理器可以重排序A和B之間的執(zhí)行順序。下圖是該程序的兩種執(zhí)行順序： as-if-serial語(yǔ)義把單線程程序保護(hù)了起來(lái)，遵守as-if-serial語(yǔ)義的編譯器，runtime 和處理器共同為編寫(xiě)單線程程序的程序員創(chuàng)建了一個(gè)幻覺(jué)：單線程程序是按程序的順序來(lái)執(zhí)行的。as-if-serial語(yǔ)義使單線程程序員無(wú)需擔(dān)心重排序會(huì)干擾他們，也無(wú)需擔(dān)心內(nèi)存可見(jiàn)性問(wèn)題。

程序順序規(guī)則

根據(jù)happens- before的程序順序規(guī)則，上面計(jì)算圓的面積的示例代碼存在三個(gè)happens- before關(guān)系：

• A happens- before B；
• B happens- before C；
• A happens- before C；

這里的第3個(gè)happens- before關(guān)系，是根據(jù)happens- before的傳遞性推導(dǎo)出來(lái)的。

這里A happens- before B，但實(shí)際執(zhí)行時(shí)B卻可以排在A之前執(zhí)行（看上面的重排序后的執(zhí)行順序）。在第一章提到過(guò)，如果A happens- before B，JMM并不要求A一定要在B之前執(zhí)行。JMM僅僅要求前一個(gè)操作（執(zhí)行的結(jié)果）對(duì)后一個(gè)操作可見(jiàn)，且前一個(gè)操作按順序排在第二個(gè)操作之前。這里操作A的執(zhí)行結(jié)果不需要對(duì)操作B可見(jiàn)；而且重排序操作A和操作B后的執(zhí)行結(jié)果，與操作A和操作B按happens- before順序執(zhí)行的結(jié)果一致。在這種情況下，JMM會(huì)認(rèn)為這種重排序并不非法（not illegal），JMM允許這種重排序。

在計(jì)算機(jī)中，軟件技術(shù)和硬件技術(shù)有一個(gè)共同的目標(biāo)：在不改變程序執(zhí)行結(jié)果的前提下，盡可能的開(kāi)發(fā)并行度。編譯器和處理器遵從這一目標(biāo)，從happens- before的定義我們可以看出，JMM同樣遵從這一目標(biāo)。

重排序?qū)Χ嗑€程的影響

現(xiàn)在讓我們來(lái)看看，重排序是否會(huì)改變多線程程序的執(zhí)行結(jié)果。請(qǐng)看下面的示例代碼：

class ReorderExample { int a = 0; boolean flag = false;public void writer() {a = 1; //1flag = true; //2 }Public void reader() {if (flag) { //3int i = a * a; //4……} } } 復(fù)制代碼

flag變量是個(gè)標(biāo)記，用來(lái)標(biāo)識(shí)變量a是否已被寫(xiě)入。這里假設(shè)有兩個(gè)線程A和B，A首先執(zhí)行writer()方法，隨后B線程接著執(zhí)行reader()方法。線程B在執(zhí)行操作4時(shí)，能否看到線程A在操作1對(duì)共享變量a的寫(xiě)入？

答案是：不一定能看到。

由于操作1和操作2沒(méi)有數(shù)據(jù)依賴關(guān)系，編譯器和處理器可以對(duì)這兩個(gè)操作重排序；同樣，操作3和操作4沒(méi)有數(shù)據(jù)依賴關(guān)系，編譯器和處理器也可以對(duì)這兩個(gè)操作重排序。讓我們先來(lái)看看，當(dāng)操作1和操作2重排序時(shí)，可能會(huì)產(chǎn)生什么效果？請(qǐng)看下面的程序執(zhí)行時(shí)序圖：

如上圖所示，操作1和操作2做了重排序。程序執(zhí)行時(shí)，線程A首先寫(xiě)標(biāo)記變量flag，隨后線程B讀這個(gè)變量。由于條件判斷為真，線程B將讀取變量a。此時(shí)，變量a還根本沒(méi)有被線程A寫(xiě)入，在這里多線程程序的語(yǔ)義被重排序破壞了！

下面再讓我們看看，當(dāng)操作3和操作4重排序時(shí)會(huì)產(chǎn)生什么效果（借助這個(gè)重排序，可以順便說(shuō)明控制依賴性）。下面是操作3和操作4重排序后，程序的執(zhí)行時(shí)序圖：

在程序中，操作3和操作4存在控制依賴關(guān)系。當(dāng)代碼中存在控制依賴性時(shí)，會(huì)影響指令序列執(zhí)行的并行度。為此，編譯器和處理器會(huì)采用猜測(cè)（Speculation）執(zhí)行來(lái)克服控制相關(guān)性對(duì)并行度的影響。以處理器的猜測(cè)執(zhí)行為例，執(zhí)行線程B的處理器可以提前讀取并計(jì)算a*a，然后把計(jì)算結(jié)果臨時(shí)保存到一個(gè)名為重排序緩沖（reorder buffer ROB）的硬件緩存中。當(dāng)接下來(lái)操作3的條件判斷為真時(shí)，就把該計(jì)算結(jié)果寫(xiě)入變量i中。

從圖中我們可以看出，猜測(cè)執(zhí)行實(shí)質(zhì)上對(duì)操作3和4做了重排序。重排序在這里破壞了多線程程序的語(yǔ)義！

在單線程程序中，對(duì)存在控制依賴的操作重排序，不會(huì)改變執(zhí)行結(jié)果（這也是as-if-serial語(yǔ)義允許對(duì)存在控制依賴的操作做重排序的原因）；但在多線程程序中，對(duì)存在控制依賴的操作重排序，可能會(huì)改變程序的執(zhí)行結(jié)果。

數(shù)據(jù)競(jìng)爭(zhēng)與順序一致性保證

當(dāng)程序未正確同步時(shí)，就會(huì)存在數(shù)據(jù)競(jìng)爭(zhēng)。java內(nèi)存模型規(guī)范對(duì)數(shù)據(jù)競(jìng)爭(zhēng)的定義如下：

• 在一個(gè)線程中寫(xiě)一個(gè)變量，
• 在另一個(gè)線程讀同一個(gè)變量，
• 而且寫(xiě)和讀沒(méi)有通過(guò)同步來(lái)排序。

當(dāng)代碼中包含數(shù)據(jù)競(jìng)爭(zhēng)時(shí)，程序的執(zhí)行往往產(chǎn)生違反直覺(jué)的結(jié)果（前一章的示例正是如此）。如果一個(gè)多線程程序能正確同步，這個(gè)程序?qū)⑹且粋€(gè)沒(méi)有數(shù)據(jù)競(jìng)爭(zhēng)的程序。

JMM對(duì)正確同步的多線程程序的內(nèi)存一致性做了如下保證：

如果程序是正確同步的，程序的執(zhí)行將具有順序一致性（sequentially consistent）– 即程序的執(zhí)行結(jié)果與該程序在順序一致性內(nèi)存模型中的執(zhí)行結(jié)果相同（馬上我們將會(huì)看到，這對(duì)于程序員來(lái)說(shuō)是一個(gè)極強(qiáng)的保證）。這里的同步是指廣義上的同步，包括對(duì)常用同步原語(yǔ)（lock，volatile和final）的正確使用。

順序一致性內(nèi)存模型

順序一致性內(nèi)存模型是一個(gè)被計(jì)算機(jī)科學(xué)家理想化了的理論參考模型，它為程序員提供了極強(qiáng)的內(nèi)存可見(jiàn)性保證。順序一致性內(nèi)存模型有兩大特性：

• 一個(gè)線程中的所有操作必須按照程序的順序來(lái)執(zhí)行。
• （不管程序是否同步）所有線程都只能看到一個(gè)單一的操作執(zhí)行順序。在順序一致性內(nèi)存模型中，每個(gè)操作都必須原子執(zhí)行且立刻對(duì)所有線程可見(jiàn)。

順序一致性內(nèi)存模型為程序員提供的視圖如下：

在概念上，順序一致性模型有一個(gè)單一的全局內(nèi)存，這個(gè)內(nèi)存通過(guò)一個(gè)左右擺動(dòng)的開(kāi)關(guān)可以連接到任意一個(gè)線程。同時(shí)，每一個(gè)線程必須按程序的順序來(lái)執(zhí)行內(nèi)存讀/寫(xiě)操作。從上圖我們可以看出，在任意時(shí)間點(diǎn)最多只能有一個(gè)線程可以連接到內(nèi)存。當(dāng)多個(gè)線程并發(fā)執(zhí)行時(shí)，圖中的開(kāi)關(guān)裝置能把所有線程的所有內(nèi)存讀/寫(xiě)操作串行化。

假設(shè)有兩個(gè)線程A和B并發(fā)執(zhí)行。其中A線程有三個(gè)操作，它們?cè)诔绦蛑械捻樞蚴?#xff1a;A1->A2->A3。B線程也有三個(gè)操作，它們?cè)诔绦蛑械捻樞蚴?#xff1a;B1->B2->B3。

假設(shè)這兩個(gè)線程使用監(jiān)視器來(lái)正確同步：A線程的三個(gè)操作執(zhí)行后釋放監(jiān)視器，隨后B線程獲取同一個(gè)監(jiān)視器。那么程序在順序一致性模型中的執(zhí)行效果將如下圖所示：

現(xiàn)在我們?cè)偌僭O(shè)這兩個(gè)線程沒(méi)有做同步，下面是這個(gè)未同步程序在順序一致性模型中的執(zhí)行示意圖：

未同步程序在順序一致性模型中雖然整體執(zhí)行順序是無(wú)序的，但所有線程都只能看到一個(gè)一致的整體執(zhí)行順序。以上圖為例，線程A和B看到的執(zhí)行順序都是：B1->A1->A2->B2->A3->B3。之所以能得到這個(gè)保證是因?yàn)轫樞蛞恢滦詢?nèi)存模型中的每個(gè)操作必須立即對(duì)任意線程可見(jiàn)。

但是，在JMM中就沒(méi)有這個(gè)保證。未同步程序在JMM中不但整體的執(zhí)行順序是無(wú)序的，而且所有線程看到的操作執(zhí)行順序也可能不一致。比如，在當(dāng)前線程把寫(xiě)過(guò)的數(shù)據(jù)緩存在本地內(nèi)存中，且還沒(méi)有刷新到主內(nèi)存之前，這個(gè)寫(xiě)操作僅對(duì)當(dāng)前線程可見(jiàn)；從其他線程的角度來(lái)觀察，會(huì)認(rèn)為這個(gè)寫(xiě)操作根本還沒(méi)有被當(dāng)前線程執(zhí)行。只有當(dāng)前線程把本地內(nèi)存中寫(xiě)過(guò)的數(shù)據(jù)刷新到主內(nèi)存之后，這個(gè)寫(xiě)操作才能對(duì)其他線程可見(jiàn)。在這種情況下，當(dāng)前線程和其它線程看到的操作執(zhí)行順序?qū)⒉灰恢隆?/p>

同步程序的順序一致性效果

下面我們對(duì)前面的示例程序ReorderExample用監(jiān)視器來(lái)同步，看看正確同步的程序如何具有順序一致性。

請(qǐng)看下面的示例代碼：

class SynchronizedExample { int a = 0; boolean flag = false;public synchronized void writer() {a = 1;flag = true; }public synchronized void reader() {if (flag) {int i = a;……} } } 復(fù)制代碼

上面示例代碼中，假設(shè)A線程執(zhí)行writer()方法后，B線程執(zhí)行reader()方法。這是一個(gè)正確同步的多線程程序。根據(jù)JMM規(guī)范，該程序的執(zhí)行結(jié)果將與該程序在順序一致性模型中的執(zhí)行結(jié)果相同。下面是該程序在兩個(gè)內(nèi)存模型中的執(zhí)行時(shí)序?qū)Ρ葓D：

在順序一致性模型中，所有操作完全按程序的順序串行執(zhí)行。而在JMM中，臨界區(qū)內(nèi)的代碼可以重排序（但JMM不允許臨界區(qū)內(nèi)的代碼“逸出”到臨界區(qū)之外，那樣會(huì)破壞監(jiān)視器的語(yǔ)義）。JMM會(huì)在退出監(jiān)視器和進(jìn)入監(jiān)視器這兩個(gè)關(guān)鍵時(shí)間點(diǎn)做一些特別處理，使得線程在這兩個(gè)時(shí)間點(diǎn)具有與順序一致性模型相同的內(nèi)存視圖（具體細(xì)節(jié)后文會(huì)說(shuō)明）。雖然線程A在臨界區(qū)內(nèi)做了重排序，但由于監(jiān)視器的互斥執(zhí)行的特性，這里的線程B根本無(wú)法“觀察”到線程A在臨界區(qū)內(nèi)的重排序。這種重排序既提高了執(zhí)行效率，又沒(méi)有改變程序的執(zhí)行結(jié)果。

從這里我們可以看到JMM在具體實(shí)現(xiàn)上的基本方針：在不改變（正確同步的）程序執(zhí)行結(jié)果的前提下，盡可能的為編譯器和處理器的優(yōu)化打開(kāi)方便之門。

未同步程序的執(zhí)行特性

對(duì)于未同步或未正確同步的多線程程序，JMM只提供最小安全性：線程執(zhí)行時(shí)讀取到的值，要么是之前某個(gè)線程寫(xiě)入的值，要么是默認(rèn)值（0，null，false），JMM保證線程讀操作讀取到的值不會(huì)無(wú)中生有（out of thin air）的冒出來(lái)。為了實(shí)現(xiàn)最小安全性，JVM在堆上分配對(duì)象時(shí)，首先會(huì)清零內(nèi)存空間，然后才會(huì)在上面分配對(duì)象（JVM內(nèi)部會(huì)同步這兩個(gè)操作）。因此，在以清零的內(nèi)存空間（pre-zeroed memory）分配對(duì)象時(shí)，域的默認(rèn)初始化已經(jīng)完成了。

JMM不保證未同步程序的執(zhí)行結(jié)果與該程序在順序一致性模型中的執(zhí)行結(jié)果一致。因?yàn)槲赐匠绦蛟陧樞蛞恢滦阅Ｐ椭袌?zhí)行時(shí)，整體上是無(wú)序的，其執(zhí)行結(jié)果無(wú)法預(yù)知。保證未同步程序在兩個(gè)模型中的執(zhí)行結(jié)果一致毫無(wú)意義。

和順序一致性模型一樣，未同步程序在JMM中的執(zhí)行時(shí)，整體上也是無(wú)序的，其執(zhí)行結(jié)果也無(wú)法預(yù)知。同時(shí)，未同步程序在這兩個(gè)模型中的執(zhí)行特性有下面幾個(gè)差異：

• 順序一致性模型保證單線程內(nèi)的操作會(huì)按程序的順序執(zhí)行，而JMM不保證單線程內(nèi)的操作會(huì)按程序的順序執(zhí)行（比如上面正確同步的多線程程序在臨界區(qū)內(nèi)的重排序）。這一點(diǎn)前面已經(jīng)講過(guò)了，這里就不再贅述。
• 順序一致性模型保證所有線程只能看到一致的操作執(zhí)行順序，而JMM不保證所有線程能看到一致的操作執(zhí)行順序。這一點(diǎn)前面也已經(jīng)講過(guò)，這里就不再贅述。
• JMM不保證對(duì)64位的long型和double型變量的讀/寫(xiě)操作具有原子性，而順序一致性模型保證對(duì)所有的內(nèi)存讀/寫(xiě)操作都具有原子性。

第3個(gè)差異與處理器總線的工作機(jī)制密切相關(guān)。在計(jì)算機(jī)中，數(shù)據(jù)通過(guò)總線在處理器和內(nèi)存之間傳遞。每次處理器和內(nèi)存之間的數(shù)據(jù)傳遞都是通過(guò)一系列步驟來(lái)完成的，這一系列步驟稱之為總線事務(wù)（bus transaction）。總線事務(wù)包括讀事務(wù)（read transaction）和寫(xiě)事務(wù)（write transaction）。讀事務(wù)從內(nèi)存?zhèn)魉蛿?shù)據(jù)到處理器，寫(xiě)事務(wù)從處理器傳送數(shù)據(jù)到內(nèi)存，每個(gè)事務(wù)會(huì)讀/寫(xiě)內(nèi)存中一個(gè)或多個(gè)物理上連續(xù)的字。這里的關(guān)鍵是，總線會(huì)同步試圖并發(fā)使用總線的事務(wù)。在一個(gè)處理器執(zhí)行總線事務(wù)期間，總線會(huì)禁止其它所有的處理器和I/O設(shè)備執(zhí)行內(nèi)存的讀/寫(xiě)。下面讓我們通過(guò)一個(gè)示意圖來(lái)說(shuō)明總線的工作機(jī)制：

如上圖所示，假設(shè)處理器A，B和C同時(shí)向總線發(fā)起總線事務(wù)，這時(shí)總線仲裁（bus arbitration）會(huì)對(duì)競(jìng)爭(zhēng)作出裁決，這里我們假設(shè)總線在仲裁后判定處理器A在競(jìng)爭(zhēng)中獲勝（總線仲裁會(huì)確保所有處理器都能公平的訪問(wèn)內(nèi)存）。此時(shí)處理器A繼續(xù)它的總線事務(wù)，而其它兩個(gè)處理器則要等待處理器A的總線事務(wù)完成后才能開(kāi)始再次執(zhí)行內(nèi)存訪問(wèn)。假設(shè)在處理器A執(zhí)行總線事務(wù)期間（不管這個(gè)總線事務(wù)是讀事務(wù)還是寫(xiě)事務(wù)），處理器D向總線發(fā)起了總線事務(wù)，此時(shí)處理器D的這個(gè)請(qǐng)求會(huì)被總線禁止。

總線的這些工作機(jī)制可以把所有處理器對(duì)內(nèi)存的訪問(wèn)以串行化的方式來(lái)執(zhí)行；在任意時(shí)間點(diǎn)，最多只能有一個(gè)處理器能訪問(wèn)內(nèi)存。這個(gè)特性確保了單個(gè)總線事務(wù)之中的內(nèi)存讀/寫(xiě)操作具有原子性。

在一些32位的處理器上，如果要求對(duì)64位數(shù)據(jù)的讀/寫(xiě)操作具有原子性，會(huì)有比較大的開(kāi)銷。為了照顧這種處理器，java語(yǔ)言規(guī)范鼓勵(lì)但不強(qiáng)求JVM對(duì)64位的long型變量和double型變量的讀/寫(xiě)具有原子性。當(dāng)JVM在這種處理器上運(yùn)行時(shí)，會(huì)把一個(gè)64位long/ double型變量的讀/寫(xiě)操作拆分為兩個(gè)32位的讀/寫(xiě)操作來(lái)執(zhí)行。這兩個(gè)32位的讀/寫(xiě)操作可能會(huì)被分配到不同的總線事務(wù)中執(zhí)行，此時(shí)對(duì)這個(gè)64位變量的讀/寫(xiě)將不具有原子性。

當(dāng)單個(gè)內(nèi)存操作不具有原子性，將可能會(huì)產(chǎn)生意想不到后果。請(qǐng)看下面示意圖：

如上圖所示，假設(shè)處理器A寫(xiě)一個(gè)long型變量，同時(shí)處理器B要讀這個(gè)long型變量。處理器A中64位的寫(xiě)操作被拆分為兩個(gè)32位的寫(xiě)操作，且這兩個(gè)32位的寫(xiě)操作被分配到不同的寫(xiě)事務(wù)中執(zhí)行。同時(shí)處理器B中64位的讀操作被拆分為兩個(gè)32位的讀操作，且這兩個(gè)32位的讀操作被分配到同一個(gè)的讀事務(wù)中執(zhí)行。當(dāng)處理器A和B按上圖的時(shí)序來(lái)執(zhí)行時(shí)，處理器B將看到僅僅被處理器A“寫(xiě)了一半“的無(wú)效值。

volatile的特性

當(dāng)我們聲明共享變量為volatile后，對(duì)這個(gè)變量的讀/寫(xiě)將會(huì)很特別。理解volatile特性的一個(gè)好方法是：把對(duì)volatile變量的單個(gè)讀/寫(xiě)，看成是使用同一個(gè)鎖對(duì)這些單個(gè)讀/寫(xiě)操作做了同步。下面我們通過(guò)具體的示例來(lái)說(shuō)明，請(qǐng)看下面的示例代碼：

class VolatileFeaturesExample {//使用volatile聲明64位的long型變量volatile long vl = 0L;public void set(long l) {vl = l; //單個(gè)volatile變量的寫(xiě)}public void getAndIncrement () {vl++; //復(fù)合（多個(gè)）volatile變量的讀/寫(xiě)}public long get() {return vl; //單個(gè)volatile變量的讀} } 復(fù)制代碼

假設(shè)有多個(gè)線程分別調(diào)用上面程序的三個(gè)方法，這個(gè)程序在語(yǔ)義上和下面程序等價(jià)：

class VolatileFeaturesExample {long vl = 0L; // 64位的long型普通變量//對(duì)單個(gè)的普通 變量的寫(xiě)用同一個(gè)鎖同步public synchronized void set(long l) { vl = l;}public void getAndIncrement () { //普通方法調(diào)用long temp = get(); //調(diào)用已同步的讀方法temp += 1L; //普通寫(xiě)操作set(temp); //調(diào)用已同步的寫(xiě)方法}public synchronized long get() { //對(duì)單個(gè)的普通變量的讀用同一個(gè)鎖同步return vl;} } 復(fù)制代碼

如上面示例程序所示，對(duì)一個(gè)volatile變量的單個(gè)讀/寫(xiě)操作，與對(duì)一個(gè)普通變量的讀/寫(xiě)操作使用同一個(gè)鎖來(lái)同步，它們之間的執(zhí)行效果相同。

鎖的happens-before規(guī)則保證釋放鎖和獲取鎖的兩個(gè)線程之間的內(nèi)存可見(jiàn)性，這意味著對(duì)一個(gè)volatile變量的讀，總是能看到（任意線程）對(duì)這個(gè)volatile變量最后的寫(xiě)入。

鎖的語(yǔ)義決定了臨界區(qū)代碼的執(zhí)行具有原子性。這意味著即使是64位的long型和double型變量，只要它是volatile變量，對(duì)該變量的讀寫(xiě)就將具有原子性。如果是多個(gè)volatile操作或類似于volatile++這種復(fù)合操作，這些操作整體上不具有原子性。

簡(jiǎn)而言之，volatile變量自身具有下列特性：

• 可見(jiàn)性。對(duì)一個(gè)volatile變量的讀，總是能看到（任意線程）對(duì)這個(gè)volatile變量最后的寫(xiě)入。
• 原子性：對(duì)任意單個(gè)volatile變量的讀/寫(xiě)具有原子性，但類似于volatile++這種復(fù)合操作不具有原子性。

volatile的寫(xiě)-讀建立的happens before關(guān)系

上面講的是volatile變量自身的特性，對(duì)程序員來(lái)說(shuō)，volatile對(duì)線程的內(nèi)存可見(jiàn)性的影響比volatile自身的特性更為重要，也更需要我們?nèi)リP(guān)注。

從JSR-133開(kāi)始，volatile變量的寫(xiě)-讀可以實(shí)現(xiàn)線程之間的通信。

從內(nèi)存語(yǔ)義的角度來(lái)說(shuō)，volatile與鎖有相同的效果：volatile寫(xiě)和鎖的釋放有相同的內(nèi)存語(yǔ)義；volatile讀與鎖的獲取有相同的內(nèi)存語(yǔ)義。

請(qǐng)看下面使用volatile變量的示例代碼：

class VolatileExample {int a = 0;volatile boolean flag = false;public void writer() {a = 1; //1flag = true; //2}public void reader() {if (flag) { //3int i = a; //4……}} } 復(fù)制代碼

假設(shè)線程A執(zhí)行writer()方法之后，線程B執(zhí)行reader()方法。根據(jù)happens before規(guī)則，這個(gè)過(guò)程建立的happens before 關(guān)系可以分為兩類：

• 根據(jù)程序次序規(guī)則，1 happens before 2; 3 happens before 4。
• 根據(jù)volatile規(guī)則，2 happens before 3。
• 根據(jù)happens before 的傳遞性規(guī)則，1 happens before 4。

上述 happens before 關(guān)系的圖形化表現(xiàn)形式如下：

在上圖中，每一個(gè)箭頭鏈接的兩個(gè)節(jié)點(diǎn)，代表了一個(gè) happens before 關(guān)系。黑色箭頭表示程序順序規(guī)則；橙色箭頭表示 volatile 規(guī)則；藍(lán)色箭頭表示組合這些規(guī)則后提供的 happens before 保證。

這里A線程寫(xiě)一個(gè)volatile變量后，B線程讀同一個(gè)volatile變量。A線程在寫(xiě)volatile變量之前所有可見(jiàn)的共享變量，在B線程讀同一個(gè)volatile變量后，將立即變得對(duì)B線程可見(jiàn)。

volatile寫(xiě)-讀的內(nèi)存語(yǔ)義

volatile 寫(xiě)的內(nèi)存語(yǔ)義如下：

當(dāng)寫(xiě)一個(gè) volatile 變量時(shí)，JMM 會(huì)把該線程對(duì)應(yīng)的本地內(nèi)存中的共享變量刷新到主內(nèi)存。 以上面示例程序 VolatileExample 為例，假設(shè)線程 A 首先執(zhí)行 writer() 方法，隨后線程 B 執(zhí)行 reader() 方法，初始時(shí)兩個(gè)線程的本地內(nèi)存中的 flag 和 a 都是初始狀態(tài)。下圖是線程 A 執(zhí)行 volatile 寫(xiě)后，共享變量的狀態(tài)示意圖：

如上圖所示，線程A在寫(xiě)flag變量后，本地內(nèi)存A中被線程A更新過(guò)的兩個(gè)共享變量的值被刷新到主內(nèi)存中。此時(shí)，本地內(nèi)存A和主內(nèi)存中的共享變量的值是一致的。

volatile讀的內(nèi)存語(yǔ)義如下：

當(dāng)讀一個(gè) volatile 變量時(shí)，JMM 會(huì)把該線程對(duì)應(yīng)的本地內(nèi)存置為無(wú)效。線程接下來(lái)將從主內(nèi)存中讀取共享變量。 下面是線程B讀同一個(gè) volatile 變量后，共享變量的狀態(tài)示意圖：

如上圖所示，在讀 flag 變量后，本地內(nèi)存 B 已經(jīng)被置為無(wú)效。此時(shí)，線程 B 必須從主內(nèi)存中讀取共享變量。線程 B 的讀取操作將導(dǎo)致本地內(nèi)存B與主內(nèi)存中的共享變量的值也變成一致的了。

如果我們把 volatile 寫(xiě)和 volatile 讀這兩個(gè)步驟綜合起來(lái)看的話，在讀線程 B 讀一個(gè)volatile 變量后，寫(xiě)線程 A 在寫(xiě)這個(gè) volatile 變量之前所有可見(jiàn)的共享變量的值都將立即變得對(duì)讀線程 B 可見(jiàn)。

下面對(duì) volatile 寫(xiě)和 volatile 讀的內(nèi)存語(yǔ)義做個(gè)總結(jié)：

• 線程 A 寫(xiě)一個(gè) volatile 變量，實(shí)質(zhì)上是線程 A 向接下來(lái)將要讀這個(gè) volatile 變量的某個(gè)線程發(fā)出了（其對(duì)共享變量所在修改的）消息。
• 線程 B 讀一個(gè) volatile 變量，實(shí)質(zhì)上是線程 B 接收了之前某個(gè)線程發(fā)出的（在寫(xiě)這個(gè)volatile 變量之前對(duì)共享變量所做修改的）消息。
• 線程A寫(xiě)一個(gè) volatile 變量，隨后線程 B 讀這個(gè) volatile 變量，這個(gè)過(guò)程實(shí)質(zhì)上是線程A 通過(guò)主內(nèi)存向線程 B 發(fā)送消息。

volatile 內(nèi)存語(yǔ)義的實(shí)現(xiàn)

JMM 如何實(shí)現(xiàn) volatile 寫(xiě)/讀的內(nèi)存語(yǔ)義。

前文我們提到過(guò)重排序分為編譯器重排序和處理器重排序。為了實(shí)現(xiàn) volatile 內(nèi)存語(yǔ)義，JMM 會(huì)分別限制這兩種類型的重排序類型。下面是 JMM 針對(duì)編譯器制定的 volatile 重排序規(guī)則表：

舉例來(lái)說(shuō)，第三行最后一個(gè)單元格的意思是：在程序順序中，當(dāng)?shù)谝粋€(gè)操作為普通變量的讀或?qū)憰r(shí)，如果第二個(gè)操作為 volatile 寫(xiě)，則編譯器不能重排序這兩個(gè)操作。

從上表我們可以看出：

• 當(dāng)?shù)诙€(gè)操作是 volatile 寫(xiě)時(shí)，不管第一個(gè)操作是什么，都不能重排序。這個(gè)規(guī)則確保volatile 寫(xiě)之前的操作不會(huì)被編譯器重排序到 volatile 寫(xiě)之后。
• 當(dāng)?shù)谝粋€(gè)操作是 volatile 讀時(shí)，不管第二個(gè)操作是什么，都不能重排序。這個(gè)規(guī)則確保volatile 讀之后的操作不會(huì)被編譯器重排序到 volatile 讀之前。
• 當(dāng)?shù)谝粋€(gè)操作是 volatile 寫(xiě)，第二個(gè)操作是 volatile 讀時(shí)，不能重排序。

為了實(shí)現(xiàn) volatile 的內(nèi)存語(yǔ)義，編譯器在生成字節(jié)碼時(shí)，會(huì)在指令序列中插入內(nèi)存屏障來(lái)禁止特定類型的處理器重排序。對(duì)于編譯器來(lái)說(shuō)，發(fā)現(xiàn)一個(gè)最優(yōu)布置來(lái)最小化插入屏障的總數(shù)幾乎不可能，為此，JMM 采取保守策略。下面是基于保守策略的 JMM 內(nèi)存屏障插入策略：

• 在每個(gè) volatile 寫(xiě)操作的前面插入一個(gè) StoreStore 屏障。
• 在每個(gè) volatile 寫(xiě)操作的后面插入一個(gè) StoreLoad 屏障。
• 在每個(gè) volatile 讀操作的后面插入一個(gè) LoadLoad 屏障。
• 在每個(gè) volatile 讀操作的后面插入一個(gè) LoadStore 屏障。

上述內(nèi)存屏障插入策略非常保守，但它可以保證在任意處理器平臺(tái)，任意的程序中都能得到正確的volatile 內(nèi)存語(yǔ)義。

下面是保守策略下，volatile 寫(xiě) 插入內(nèi)存屏障后生成的指令序列示意圖：

上圖中的 StoreStore 屏障可以保證在 volatile 寫(xiě)之前，其前面的所有普通寫(xiě)操作已經(jīng)對(duì)任意處理器可見(jiàn)了。這是因?yàn)?StoreStore 屏障將保障上面所有的普通寫(xiě)在 volatile 寫(xiě)之前刷新到主內(nèi)存。

這里比較有意思的是 volatile 寫(xiě)后面的 StoreLoad 屏障。這個(gè)屏障的作用是避免 volatile寫(xiě)與后面可能有的 volatile 讀/寫(xiě)操作重排序。因?yàn)榫幾g器常常無(wú)法準(zhǔn)確判斷在一個(gè) volatile寫(xiě)的后面，是否需要插入一個(gè) StoreLoad 屏障（比如，一個(gè) volatile 寫(xiě)之后方法立即return）。為了保證能正確實(shí)現(xiàn) volatile 的內(nèi)存語(yǔ)義，JMM 在這里采取了保守策略：在每個(gè)volatile 寫(xiě)的后面或在每個(gè) volatile 讀的前面插入一個(gè) StoreLoad 屏障。從整體執(zhí)行效率的角度考慮，JMM 選擇了在每個(gè) volatile 寫(xiě)的后面插入一個(gè) StoreLoad 屏障。因?yàn)関olatile 寫(xiě)-讀內(nèi)存語(yǔ)義的常見(jiàn)使用模式是：一個(gè)寫(xiě)線程寫(xiě) volatile 變量，多個(gè)讀線程讀同一個(gè) volatile 變量。當(dāng)讀線程的數(shù)量大大超過(guò)寫(xiě)線程時(shí)，選擇在 volatile 寫(xiě)之后插入StoreLoad 屏障將帶來(lái)可觀的執(zhí)行效率的提升。從這里我們可以看到 JMM 在實(shí)現(xiàn)上的一個(gè)特點(diǎn)：首先確保正確性，然后再去追求執(zhí)行效率。

下面是在保守策略下，volatile 讀插入內(nèi)存屏障后生成的指令序列示意圖：

上圖中的 LoadLoad 屏障用來(lái)禁止處理器把上面的 volatile 讀與下面的普通讀重排序。LoadStore 屏障用來(lái)禁止處理器把上面的 volatile 讀與下面的普通寫(xiě)重排序。

上述 volatile 寫(xiě)和 volatile 讀的內(nèi)存屏障插入策略非常保守。在實(shí)際執(zhí)行時(shí)，只要不改變volatile 寫(xiě)-讀的內(nèi)存語(yǔ)義，編譯器可以根據(jù)具體情況省略不必要的屏障。下面我們通過(guò)具體的示例代碼來(lái)說(shuō)明：

class VolatileBarrierExample {int a;volatile int v1 = 1;volatile int v2 = 2;void readAndWrite() {int i = v1; //第一個(gè)volatile讀int j = v2; // 第二個(gè)volatile讀a = i + j; //普通寫(xiě)v1 = i + 1; // 第一個(gè)volatile寫(xiě)v2 = j * 2; //第二個(gè) volatile寫(xiě)}… //其他方法 } 復(fù)制代碼

針對(duì) readAndWrite() 方法，編譯器在生成字節(jié)碼時(shí)可以做如下的優(yōu)化：

注意，最后的 StoreLoad 屏障不能省略。因?yàn)榈诙€(gè) volatile 寫(xiě)之后，方法立即 return。此時(shí)編譯器可能無(wú)法準(zhǔn)確斷定后面是否會(huì)有 volatile 讀或?qū)?#xff0c;為了安全起見(jiàn)，編譯器常常會(huì)在這里插入一個(gè) StoreLoad 屏障。

上面的優(yōu)化是針對(duì)任意處理器平臺(tái)，由于不同的處理器有不同“松緊度”的處理器內(nèi)存模型，內(nèi)存屏障的插入還可以根據(jù)具體的處理器內(nèi)存模型繼續(xù)優(yōu)化。以 x86 處理器為例，上圖中除最后的StoreLoad 屏障外，其它的屏障都會(huì)被省略。

前面保守策略下的 volatile 讀和寫(xiě)，在 x86 處理器平臺(tái)可以優(yōu)化成：

前文提到過(guò)，x86 處理器僅會(huì)對(duì)寫(xiě)-讀操作做重排序。X86 不會(huì)對(duì)讀-讀，讀-寫(xiě)和寫(xiě)-寫(xiě)操作做重排序，因此在 x86 處理器中會(huì)省略掉這三種操作類型對(duì)應(yīng)的內(nèi)存屏障。在 x86 中，JMM 僅需在volatile 寫(xiě)后面插入一個(gè) StoreLoad 屏障即可正確實(shí)現(xiàn) volatile 寫(xiě)-讀的內(nèi)存語(yǔ)義。這意味著在 x86 處理器中，volatile 寫(xiě)的開(kāi)銷比 volatile 讀的開(kāi)銷會(huì)大很多（因?yàn)閳?zhí)行StoreLoad 屏障開(kāi)銷會(huì)比較大）。

JSR-133 為什么要增強(qiáng) volatile 的內(nèi)存語(yǔ)義

在 JSR-133 之前的舊 Java 內(nèi)存模型中，雖然不允許 volatile 變量之間重排序，但舊的Java 內(nèi)存模型允許 volatile 變量與普通變量之間重排序。在舊的內(nèi)存模型中，VolatileExample 示例程序可能被重排序成下列時(shí)序來(lái)執(zhí)行：

在舊的內(nèi)存模型中，當(dāng)1和2之間沒(méi)有數(shù)據(jù)依賴關(guān)系時(shí)，1和2之間就可能被重排序（3和4類似）。其結(jié)果就是：讀線程B執(zhí)行4時(shí)，不一定能看到寫(xiě)線程 A 在執(zhí)行1時(shí)對(duì)共享變量的修改。

因此在舊的內(nèi)存模型中 ，volatile 的寫(xiě)-讀沒(méi)有鎖的釋放-獲所具有的內(nèi)存語(yǔ)義。為了提供一種比鎖更輕量級(jí)的線程之間通信的機(jī)制，JSR-133 專家組決定增強(qiáng) volatile 的內(nèi)存語(yǔ)義：嚴(yán)格限制編譯器和處理器對(duì) volatile 變量與普通變量的重排序，確保 volatile 的寫(xiě)-讀和鎖的釋放-獲取一樣，具有相同的內(nèi)存語(yǔ)義。從編譯器重排序規(guī)則和處理器內(nèi)存屏障插入策略來(lái)看，只要volatile 變量與普通變量之間的重排序可能會(huì)破壞 volatile 的內(nèi)存語(yǔ)意，這種重排序就會(huì)被編譯器重排序規(guī)則和處理器內(nèi)存屏障插入策略禁止。

由于 volatile 僅僅保證對(duì)單個(gè) volatile 變量的讀/寫(xiě)具有原子性，而鎖的互斥執(zhí)行的特性可以確保對(duì)整個(gè)臨界區(qū)代碼的執(zhí)行具有原子性。在功能上，鎖比 volatile 更強(qiáng)大；在可伸縮性和執(zhí)行性能上，volatile 更有優(yōu)勢(shì)。

鎖的釋放-獲取建立的happens before 關(guān)系

鎖是java并發(fā)編程中最重要的同步機(jī)制。鎖除了讓臨界區(qū)互斥執(zhí)行外，還可以讓釋放鎖的線程向獲取同一個(gè)鎖的線程發(fā)送消息。下面是鎖釋放-獲取的示例代碼：

class MonitorExample {int a = 0;public synchronized void writer() { //1a++; //2} //3public synchronized void reader() { //4int i = a; //5……} //6 } 復(fù)制代碼

假設(shè)線程A執(zhí)行writer()方法，隨后線程B執(zhí)行reader()方法。根據(jù)happens before規(guī)則，這個(gè)過(guò)程包含的happens before 關(guān)系可以分為兩類：

• 根據(jù)程序次序規(guī)則，1 happens before 2, 2 happens before 3; 4 happens before 5, 5 happens before 6。
• 根據(jù)監(jiān)視器鎖規(guī)則，3 happens before 4。
• 根據(jù)happens before 的傳遞性，2 happens before 5。

上述happens before 關(guān)系的圖形化表現(xiàn)形式如下：

在上圖中，每一個(gè)箭頭鏈接的兩個(gè)節(jié)點(diǎn)，代表了一個(gè) happens before 關(guān)系。黑色箭頭表示程序順序規(guī)則；橙色箭頭表示監(jiān)視器鎖規(guī)則；藍(lán)色箭頭表示組合這些規(guī)則后提供的 happens before保證。

上圖表示在線程A釋放了鎖之后，隨后線程B獲取同一個(gè)鎖。在上圖中，2 happens before 5。因此，線程A在釋放鎖之前所有可見(jiàn)的共享變量，在線程B獲取同一個(gè)鎖之后，將立刻變得對(duì)B線程可見(jiàn)。

鎖釋放和獲取的內(nèi)存語(yǔ)義

當(dāng)線程釋放鎖時(shí)，JMM 會(huì)把該線程對(duì)應(yīng)的本地內(nèi)存中的共享變量刷新到主內(nèi)存中。以上面的MonitorExample 程序?yàn)槔?#xff0c;A線程釋放鎖后，共享數(shù)據(jù)的狀態(tài)示意圖如下：

當(dāng)線程獲取鎖時(shí)，JMM 會(huì)把該線程對(duì)應(yīng)的本地內(nèi)存置為無(wú)效。從而使得被監(jiān)視器保護(hù)的臨界區(qū)代碼必須要從主內(nèi)存中去讀取共享變量。下面是鎖獲取的狀態(tài)示意圖： 對(duì)比鎖釋放-獲取的內(nèi)存語(yǔ)義與 volatile 寫(xiě)-讀的內(nèi)存語(yǔ)義，可以看出：鎖釋放與 volatile 寫(xiě)有相同的內(nèi)存語(yǔ)義；鎖獲取與 volatile 讀有相同的內(nèi)存語(yǔ)義。

下面對(duì)鎖釋放和鎖獲取的內(nèi)存語(yǔ)義做個(gè)總結(jié)：

• 線程 A 釋放一個(gè)鎖，實(shí)質(zhì)上是線程 A 向接下來(lái)將要獲取這個(gè)鎖的某個(gè)線程發(fā)出了（線程 A 對(duì)共享變量所做修改的）消息。
• 線程 B 獲取一個(gè)鎖，實(shí)質(zhì)上是線程 B 接收了之前某個(gè)線程發(fā)出的（在釋放這個(gè)鎖之前對(duì)共享變量所做修改的）消息。
• 線程 A 釋放鎖，隨后線程 B 獲取這個(gè)鎖，這個(gè)過(guò)程實(shí)質(zhì)上是線程 A 通過(guò)主內(nèi)存向線程 B 發(fā)送消息。

鎖內(nèi)存語(yǔ)義的實(shí)現(xiàn)

class ReentrantLockExample { int a = 0; ReentrantLock lock = new ReentrantLock();public void writer() {lock.lock(); //獲取鎖try {a++;} finally {lock.unlock(); //釋放鎖} }public void reader () {lock.lock(); //獲取鎖try {int i = a;……} finally {lock.unlock(); //釋放鎖} } } 復(fù)制代碼

ReentrantLock 的實(shí)現(xiàn)依賴于 java 同步器框架 AbstractQueuedSynchronizer（本文簡(jiǎn)稱之為AQS）。AQS 使用一個(gè)整型的 volatile 變量（命名為 state）來(lái)維護(hù)同步狀態(tài)，馬上我們會(huì)看到，這個(gè) volatile 變量是 ReentrantLock 內(nèi)存語(yǔ)義實(shí)現(xiàn)的關(guān)鍵。 下面是ReentrantLock 的類圖（僅畫(huà)出與本文相關(guān)的部分）：

ReentrantLock 分為公平鎖和非公平鎖。

使用公平鎖時(shí)，加鎖方法 lock() 的方法調(diào)用軌跡如下：

• ReentrantLock : lock()
• FairSync : lock()
• AbstractQueuedSynchronizer : acquire(int arg)
• ReentrantLock : tryAcquire(int acquires)

在第4步真正開(kāi)始加鎖，下面是該方法的源代碼：

protected final boolean tryAcquire(int acquires) {final Thread current = Thread.currentThread();int c = getState(); //獲取鎖的開(kāi)始，首先讀volatile變量stateif (c == 0) {if (isFirst(current) &&compareAndSetState(0, acquires)) {setExclusiveOwnerThread(current);return true;}}else if (current == getExclusiveOwnerThread()) {int nextc = c + acquires;if (nextc < 0) throw new Error("Maximum lock count exceeded");setState(nextc);return true;}return false; } 復(fù)制代碼

從上面源代碼中我們可以看出，加鎖方法首先讀 volatile 變量 state。

在使用公平鎖時(shí)，解鎖方法 unlock() 的方法調(diào)用軌跡如下：

• ReentrantLock : unlock()
• AbstractQueuedSynchronizer : release(int arg)
• Sync : tryRelease(int releases)

在第3步真正開(kāi)始釋放鎖，下面是該方法的源代碼：

protected final boolean tryRelease(int releases) {int c = getState() - releases;if (Thread.currentThread() != getExclusiveOwnerThread())throw new IllegalMonitorStateException();boolean free = false;if (c == 0) {free = true;setExclusiveOwnerThread(null);}setState(c); //釋放鎖的最后，寫(xiě)volatile變量statereturn free; } 復(fù)制代碼

從上面的源代碼我們可以看出，在釋放鎖的最后寫(xiě) volatile 變量 state。

公平鎖在釋放鎖的最后寫(xiě) volatile 變量 state；在獲取鎖時(shí)首先讀這個(gè) volatile 變量。根據(jù) volatile 的 happens-before 規(guī)則，釋放鎖的線程在寫(xiě) volatile 變量之前可見(jiàn)的共享變量，在獲取鎖的線程讀取同一個(gè) volatile 變量后將立即變的對(duì)獲取鎖的線程可見(jiàn)。

使用非公平鎖時(shí)，加鎖方法 lock() 的方法調(diào)用軌跡如下：

• ReentrantLock : lock()
• NonfairSync : lock()
• AbstractQueuedSynchronizer : compareAndSetState(int expect, int update)

在第3步真正開(kāi)始加鎖，下面是該方法的源代碼：

protected final boolean compareAndSetState(int expect, int update) {return unsafe.compareAndSwapInt(this, stateOffset, expect, update); } 復(fù)制代碼

該方法以原子操作的方式更新 state 變量，本文把 java 的 compareAndSet() 方法調(diào)用簡(jiǎn)稱為 CAS。JDK 文檔對(duì)該方法的說(shuō)明如下：如果當(dāng)前狀態(tài)值等于預(yù)期值，則以原子方式將同步狀態(tài)設(shè)置為給定的更新值。此操作具有 volatile 讀和寫(xiě)的內(nèi)存語(yǔ)義。

這里我們分別從編譯器和處理器的角度來(lái)分析,CAS 如何同時(shí)具有 volatile 讀和 volatile 寫(xiě)的內(nèi)存語(yǔ)義。

前文我們提到過(guò)，編譯器不會(huì)對(duì) volatile 讀與 volatile 讀后面的任意內(nèi)存操作重排序；編譯器不會(huì)對(duì) volatile 寫(xiě)與 volatile 寫(xiě)前面的任意內(nèi)存操作重排序。組合這兩個(gè)條件，意味著為了同時(shí)實(shí)現(xiàn) volatile 讀和 volatile 寫(xiě)的內(nèi)存語(yǔ)義，編譯器不能對(duì) CAS 與 CAS 前面和后面的任意內(nèi)存操作重排序。

下面我們來(lái)分析在常見(jiàn)的 intel x86 處理器中，CAS 是如何同時(shí)具有 volatile 讀和 volatile 寫(xiě)的內(nèi)存語(yǔ)義的。

下面是 sun.misc.Unsafe 類的 compareAndSwapInt() 方法的源代碼：

public final native boolean compareAndSwapInt(Object o, long offset,int expected,int x); 復(fù)制代碼

可以看到這是個(gè)本地方法調(diào)用。這個(gè)本地方法在 openjdk 中依次調(diào)用的 C++ 代碼為：unsafe.cpp，atomic.cpp 和 atomicwindowsx86.inline.hpp。這個(gè)本地方法的最終實(shí)現(xiàn)在 openjdk 的如下位置：openjdk-7-fcs-src-b147-27jun2011\openjdk\hotspot\src\oscpu\windowsx86\vm\ atomicwindowsx86.inline.hpp（對(duì)應(yīng)于 windows 操作系統(tǒng)，X86 處理器）。下面是對(duì)應(yīng)于 intel x86 處理器的源代碼的片段：

// Adding a lock prefix to an instruction on MP machine // VC++ doesn't like the lock prefix to be on a single line // so we can't insert a label after the lock prefix. // By emitting a lock prefix, we can define a label after it. #define LOCK_IF_MP(mp) __asm cmp mp, 0 \__asm je L0 \__asm _emit 0xF0 \__asm L0:inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {// alternative for InterlockedCompareExchangeint mp = os::is_MP();__asm {mov edx, destmov ecx, exchange_valuemov eax, compare_valueLOCK_IF_MP(mp)cmpxchg dword ptr [edx], ecx} } 復(fù)制代碼

如上面源代碼所示，程序會(huì)根據(jù)當(dāng)前處理器的類型來(lái)決定是否為 cmpxchg 指令添加 lock 前綴。如果程序是在多處理器上運(yùn)行，就為 cmpxchg 指令加上 lock 前綴（lock cmpxchg）。反之，如果程序是在單處理器上運(yùn)行，就省略 lock 前綴（單處理器自身會(huì)維護(hù)單處理器內(nèi)的順序一致性，不需要 lock 前綴提供的內(nèi)存屏障效果）。

intel 的手冊(cè)對(duì) lock 前綴的說(shuō)明如下：

• 確保對(duì)內(nèi)存的讀-改-寫(xiě)操作原子執(zhí)行。在 Pentium 及 Pentium 之前的處理器中，帶有l(wèi)ock 前綴的指令在執(zhí)行期間會(huì)鎖住總線，使得其他處理器暫時(shí)無(wú)法通過(guò)總線訪問(wèn)內(nèi)存。很顯然，這會(huì)帶來(lái)昂貴的開(kāi)銷。從 Pentium 4，Intel Xeon 及 P6 處理器開(kāi)始，intel 在原有總線鎖的基礎(chǔ)上做了一個(gè)很有意義的優(yōu)化：如果要訪問(wèn)的內(nèi)存區(qū)域（area of memory）在 lock 前綴指令執(zhí)行期間已經(jīng)在處理器內(nèi)部的緩存中被鎖定（即包含該內(nèi)存區(qū)域的緩存行當(dāng)前處于獨(dú)占或以修改狀態(tài)），并且該內(nèi)存區(qū)域被完全包含在單個(gè)緩存行（cache line）中，那么處理器將直接執(zhí)行該指令。由于在指令執(zhí)行期間該緩存行會(huì)一直被鎖定，其它處理器無(wú)法讀/寫(xiě)該指令要訪問(wèn)的內(nèi)存區(qū)域，因此能保證指令執(zhí)行的原子性。這個(gè)操作過(guò)程叫做緩存鎖定（cache locking），緩存鎖定將大大降低 lock 前綴指令的執(zhí)行開(kāi)銷，但是當(dāng)多處理器之間的競(jìng)爭(zhēng)程度很高或者指令訪問(wèn)的內(nèi)存地址未對(duì)齊時(shí)，仍然會(huì)鎖住總線。
• 禁止該指令與之前和之后的讀和寫(xiě)指令重排序。
• 把寫(xiě)緩沖區(qū)中的所有數(shù)據(jù)刷新到內(nèi)存中。

上面的第2點(diǎn)和第3點(diǎn)所具有的內(nèi)存屏障效果，足以同時(shí)實(shí)現(xiàn) volatile 讀和 volatile 寫(xiě)的內(nèi)存語(yǔ)義。

經(jīng)過(guò)上面的這些分析，現(xiàn)在我們終于能明白為什么 JDK 文檔說(shuō) CAS 同時(shí)具有 volatile 讀和volatile 寫(xiě)的內(nèi)存語(yǔ)義了。

現(xiàn)在對(duì)公平鎖和非公平鎖的內(nèi)存語(yǔ)義做個(gè)總結(jié)：

• 公平鎖和非公平鎖釋放時(shí)，最后都要寫(xiě)一個(gè) volatile 變量 state。
• 公平鎖獲取時(shí)，首先會(huì)去讀這個(gè) volatile 變量。
• 非公平鎖獲取時(shí)，首先會(huì)用 CAS 更新這個(gè) volatile 變量,這個(gè)操作同時(shí)具有 volatile 讀和 volatile 寫(xiě)的內(nèi)存語(yǔ)義。

從本文對(duì) ReentrantLock 的分析可以看出，鎖釋放-獲取的內(nèi)存語(yǔ)義的實(shí)現(xiàn)至少有下面兩種方式：

• 利用 volatile 變量的寫(xiě)-讀所具有的內(nèi)存語(yǔ)義。
• 利用 CAS 所附帶的 volatile 讀和 volatile 寫(xiě)的內(nèi)存語(yǔ)義。

concurrent 包的實(shí)現(xiàn)

由于 java 的 CAS 同時(shí)具有 volatile 讀和 volatile 寫(xiě)的內(nèi)存語(yǔ)義，因此 Java 線程之間的通信現(xiàn)在有了下面四種方式：

• A 線程寫(xiě) volatile 變量，隨后 B 線程讀這個(gè) volatile 變量。
• A 線程寫(xiě) volatile 變量，隨后 B 線程用 CAS 更新這個(gè) volatile 變量。
• A 線程用 CAS 更新一個(gè)volatile變量，隨后 B 線程用 CAS 更新這個(gè) volatile 變量。
• A 線程用 CAS 更新一個(gè) volatile 變量，隨后 B 線程讀這個(gè) volatile 變量。

Java 的 CAS 會(huì)使用現(xiàn)代處理器上提供的高效機(jī)器級(jí)別原子指令，這些原子指令以原子方式對(duì)內(nèi)存執(zhí)行讀-改-寫(xiě)操作，這是在多處理器中實(shí)現(xiàn)同步的關(guān)鍵（從本質(zhì)上來(lái)說(shuō)，能夠支持原子性讀-改-寫(xiě)指令的計(jì)算機(jī)器，是順序計(jì)算圖靈機(jī)的異步等價(jià)機(jī)器，因此任何現(xiàn)代的多處理器都會(huì)去支持某種能對(duì)內(nèi)存執(zhí)行原子性讀-改-寫(xiě)操作的原子指令）。同時(shí)，volatile 變量的讀/寫(xiě)和 CAS 可以實(shí)現(xiàn)線程之間的通信。把這些特性整合在一起，就形成了整個(gè) concurrent 包得以實(shí)現(xiàn)的基石。如果我們仔細(xì)分析 concurrent 包的源代碼實(shí)現(xiàn)，會(huì)發(fā)現(xiàn)一個(gè)通用化的實(shí)現(xiàn)模式：

• 首先，聲明共享變量為 volatile；
• 然后，使用 CAS 的原子條件更新來(lái)實(shí)現(xiàn)線程之間的同步；
• 同時(shí)，配合以 volatile 的讀/寫(xiě)和 CAS 所具有的 volatile 讀和寫(xiě)的內(nèi)存語(yǔ)義來(lái)實(shí)現(xiàn)線程之間的通信。

AQS，非阻塞數(shù)據(jù)結(jié)構(gòu)和原子變量類（java.util.concurrent.atomic 包中的類），這些 concurrent 包中的基礎(chǔ)類都是使用這種模式來(lái)實(shí)現(xiàn)的，而 concurrent 包中的高層類又是依賴于這些基礎(chǔ)類來(lái)實(shí)現(xiàn)的。從整體來(lái)看，concurrent 包的實(shí)現(xiàn)示意圖如下：

final

對(duì)于final 域，編譯器和處理器要遵守兩個(gè)重排序規(guī)則：

• 在構(gòu)造函數(shù)內(nèi)對(duì)一個(gè) final 域的寫(xiě)入，與隨后把這個(gè)被構(gòu)造對(duì)象的引用賦值給一個(gè)引用變量，這兩個(gè)操作之間不能重排序。
• 初次讀一個(gè)包含 final 域的對(duì)象的引用，與隨后初次讀這個(gè) final 域，這兩個(gè)操作之間不能重排序。

下面，我們通過(guò)一些示例性的代碼來(lái)分別說(shuō)明這兩個(gè)規(guī)則：

public class FinalExample {int i; //普通變量final int j; //final變量static FinalExample obj;public void FinalExample () { //構(gòu)造函數(shù)i = 1; //寫(xiě)普通域j = 2; //寫(xiě)final域}public static void writer () { //寫(xiě)線程A執(zhí)行obj = new FinalExample ();}public static void reader () { //讀線程B執(zhí)行FinalExample object = obj; //讀對(duì)象引用int a = object.i; //讀普通域int b = object.j; //讀final域} } 復(fù)制代碼

這里假設(shè)一個(gè)線程 A 執(zhí)行 writer() 方法，隨后另一個(gè)線程 B 執(zhí)行 reader() 方法。

寫(xiě) final 域的重排序規(guī)則

寫(xiě) final 域的重排序規(guī)則禁止把 final 域的寫(xiě)重排序到構(gòu)造函數(shù)之外。這個(gè)規(guī)則的實(shí)現(xiàn)包含下面2個(gè)方面：

• JMM 禁止編譯器把 final 域的寫(xiě)重排序到構(gòu)造函數(shù)之外。
• 編譯器會(huì)在 final 域的寫(xiě)之后，構(gòu)造函數(shù) return 之前，插入一個(gè) StoreStore 屏障。這個(gè)屏障禁止處理器把 final 域的寫(xiě)重排序到構(gòu)造函數(shù)之外。

現(xiàn)在讓我們分析 writer() 方法。writer() 方法只包含一行代碼：finalExample = new FinalExample()。這行代碼包含兩個(gè)步驟：

構(gòu)造一個(gè) FinalExample 類型的對(duì)象； 把這個(gè)對(duì)象的引用賦值給引用變量 obj。 假設(shè)線程 B 讀對(duì)象引用與讀對(duì)象的成員域之間沒(méi)有重排序（馬上會(huì)說(shuō)明為什么需要這個(gè)假設(shè)），下圖是一種可能的執(zhí)行時(shí)序：

在上圖中，寫(xiě)普通域的操作被編譯器重排序到了構(gòu)造函數(shù)之外，讀線程B錯(cuò)誤的讀取了普通變量i初始化之前的值。而寫(xiě) final 域的操作，被寫(xiě) final 域的重排序規(guī)則“限定”在了構(gòu)造函數(shù)之內(nèi)，讀線程 B 正確的讀取了 final 變量初始化之后的值。

寫(xiě) final 域的重排序規(guī)則可以確保：在對(duì)象引用為任意線程可見(jiàn)之前，對(duì)象的 final 域已經(jīng)被正確初始化過(guò)了，而普通域不具有這個(gè)保障。以上圖為例，在讀線程 B “看到”對(duì)象引用 obj 時(shí)，很可能 obj 對(duì)象還沒(méi)有構(gòu)造完成（對(duì)普通域i的寫(xiě)操作被重排序到構(gòu)造函數(shù)外，此時(shí)初始值2還沒(méi)有寫(xiě)入普通域i）。

讀 final 域的重排序規(guī)則

讀 final 域的重排序規(guī)則如下：

• 在一個(gè)線程中，初次讀對(duì)象引用與初次讀該對(duì)象包含的 final 域，JMM 禁止處理器重排序這兩個(gè)操作（注意，這個(gè)規(guī)則僅僅針對(duì)處理器）。編譯器會(huì)在讀 final 域操作的前面插入一個(gè) LoadLoad 屏障。

初次讀對(duì)象引用與初次讀該對(duì)象包含的 final 域，這兩個(gè)操作之間存在間接依賴關(guān)系。由于編譯器遵守間接依賴關(guān)系，因此編譯器不會(huì)重排序這兩個(gè)操作。大多數(shù)處理器也會(huì)遵守間接依賴，大多數(shù)處理器也不會(huì)重排序這兩個(gè)操作。但有少數(shù)處理器允許對(duì)存在間接依賴關(guān)系的操作做重排序（比如 alpha 處理器），這個(gè)規(guī)則就是專門用來(lái)針對(duì)這種處理器。

reader() 方法包含三個(gè)操作：

• 初次讀引用變量 obj;
• 初次讀引用變量 obj 指向?qū)ο蟮钠胀ㄓ?j。
• 初次讀引用變量 obj 指向?qū)ο蟮?final 域 i。

現(xiàn)在我們假設(shè)寫(xiě)線程 A 沒(méi)有發(fā)生任何重排序，同時(shí)程序在不遵守間接依賴的處理器上執(zhí)行，下面是一種可能的執(zhí)行時(shí)序：

在上圖中，讀對(duì)象的普通域的操作被處理器重排序到讀對(duì)象引用之前。讀普通域時(shí)，該域還沒(méi)有被寫(xiě)線程A寫(xiě)入，這是一個(gè)錯(cuò)誤的讀取操作。而讀 final 域的重排序規(guī)則會(huì)把讀對(duì)象 final 域的操作“限定”在讀對(duì)象引用之后，此時(shí)該 final 域已經(jīng)被 A 線程初始化過(guò)了，這是一個(gè)正確的讀取操作。

讀 final 域的重排序規(guī)則可以確保：在讀一個(gè)對(duì)象的 final 域之前，一定會(huì)先讀包含這個(gè) final 域的對(duì)象的引用。在這個(gè)示例程序中，如果該引用不為 null，那么引用對(duì)象的 final 域一定已經(jīng)被 A 線程初始化過(guò)了。

如果 final 域是引用類型

public class FinalReferenceExample { final int[] intArray; //final是引用類型 static FinalReferenceExample obj;public FinalReferenceExample () { //構(gòu)造函數(shù)intArray = new int[1]; //1intArray[0] = 1; //2 }public static void writerOne () { //寫(xiě)線程A執(zhí)行obj = new FinalReferenceExample (); //3 }public static void writerTwo () { //寫(xiě)線程B執(zhí)行obj.intArray[0] = 2; //4 }public static void reader () { //讀線程C執(zhí)行if (obj != null) { //5int temp1 = obj.intArray[0]; //6} } } 復(fù)制代碼

這里 final 域?yàn)橐粋€(gè)引用類型，它引用一個(gè) int 型的數(shù)組對(duì)象。對(duì)于引用類型，寫(xiě) final 域的重排序規(guī)則對(duì)編譯器和處理器增加了如下約束：

• 在構(gòu)造函數(shù)內(nèi)對(duì)一個(gè) final 引用的對(duì)象的成員域的寫(xiě)入，與隨后在構(gòu)造函數(shù)外把這個(gè)被構(gòu)造對(duì)象的引用賦值給一個(gè)引用變量，這兩個(gè)操作之間不能重排序。

對(duì)上面的示例程序，我們假設(shè)首先線程 A 執(zhí)行 writerOne() 方法，執(zhí)行完后線程 B 執(zhí)行 writerTwo() 方法，執(zhí)行完后線程 C 執(zhí)行 reader() 方法。下面是一種可能的線程執(zhí)行時(shí)序：

在上圖中，1 是對(duì) final 域的寫(xiě)入，2 是對(duì)這個(gè) final 域引用的對(duì)象的成員域的寫(xiě)入，3是把被構(gòu)造的對(duì)象的引用賦值給某個(gè)引用變量。這里除了前面提到的1不能和3重排序外，2和3也不能重排序。

JMM 可以確保讀線程 C 至少能看到寫(xiě)線程 A 在構(gòu)造函數(shù)中對(duì) final 引用對(duì)象的成員域的寫(xiě)入。即 C 至少能看到數(shù)組下標(biāo) 0 的值為 1。而寫(xiě)線程 B 對(duì)數(shù)組元素的寫(xiě)入，讀線程 C 可能看的到，也可能看不到。JMM 不保證線程 B 的寫(xiě)入對(duì)讀線程 C 可見(jiàn)，因?yàn)閷?xiě)線程 B 和讀線程 C 之間存在數(shù)據(jù)競(jìng)爭(zhēng)，此時(shí)的執(zhí)行結(jié)果不可預(yù)知。

如果想要確保讀線程 C 看到寫(xiě)線程 B 對(duì)數(shù)組元素的寫(xiě)入，寫(xiě)線程 B 和讀線程 C 之間需要使用同步原語(yǔ)（lock 或 volatile）來(lái)確保內(nèi)存可見(jiàn)性。

為什么 final 引用不能從構(gòu)造函數(shù)內(nèi)“逸出”

前面我們提到過(guò)，寫(xiě) final 域的重排序規(guī)則可以確保：在引用變量為任意線程可見(jiàn)之前，該引用變量指向的對(duì)象的 final 域已經(jīng)在構(gòu)造函數(shù)中被正確初始化過(guò)了。其實(shí)要得到這個(gè)效果，還需要一個(gè)保證：在構(gòu)造函數(shù)內(nèi)部，不能讓這個(gè)被構(gòu)造對(duì)象的引用為其他線程可見(jiàn)，也就是對(duì)象引用不能在構(gòu)造函數(shù)中“逸出”。為了說(shuō)明問(wèn)題，讓我們來(lái)看下面示例代碼：

public class FinalReferenceEscapeExample { final int i; static FinalReferenceEscapeExample obj;public FinalReferenceEscapeExample () {i = 1; //1寫(xiě)final域obj = this; //2 this引用在此“逸出” }public static void writer() {new FinalReferenceEscapeExample (); }public static void reader {if (obj != null) { //3int temp = obj.i; //4} } } 復(fù)制代碼

假設(shè)一個(gè)線程 A 執(zhí)行 writer() 方法，另一個(gè)線程 B 執(zhí)行 reader() 方法。這里的操作2使得對(duì)象還未完成構(gòu)造前就為線程 B 可見(jiàn)。即使這里的操作 2 是構(gòu)造函數(shù)的最后一步，且即使在程序中操作 2 排在操作 1 后面，執(zhí)行 read() 方法的線程仍然可能無(wú)法看到 final 域被初始化后的值，因?yàn)檫@里的操作 1 和操作 2 之間可能被重排序。實(shí)際的執(zhí)行時(shí)序可能如下圖所示：

從上圖我們可以看出：在構(gòu)造函數(shù)返回前，被構(gòu)造對(duì)象的引用不能為其他線程可見(jiàn)，因?yàn)榇藭r(shí)的 final 域可能還沒(méi)有被初始化。在構(gòu)造函數(shù)返回后，任意線程都將保證能看到 final 域正確初始化之后的值。

final 語(yǔ)義在處理器中的實(shí)現(xiàn)

現(xiàn)在我們以 x86 處理器為例，說(shuō)明 final 語(yǔ)義在處理器中的具體實(shí)現(xiàn)。

上面我們提到，寫(xiě) final 域的重排序規(guī)則會(huì)要求譯編器在 final 域的寫(xiě)之后，構(gòu)造函數(shù)return 之前，插入一個(gè) StoreStore 障屏。讀 final 域的重排序規(guī)則要求編譯器在讀 final 域的操作前面插入一個(gè) LoadLoad 屏障。

由于 x86 處理器不會(huì)對(duì)寫(xiě)-寫(xiě)操作做重排序，所以在 x86 處理器中，寫(xiě) final 域需要的 StoreStore 障屏?xí)皇÷缘簟Ｍ瑯?#xff0c;由于 x86 處理器不會(huì)對(duì)存在間接依賴關(guān)系的操作做重排序，所以在 x86 處理器中，讀 final 域需要的 LoadLoad 屏障也會(huì)被省略掉。也就是說(shuō)在 x86 處理器中，final 域的讀/寫(xiě)不會(huì)插入任何內(nèi)存屏障！

總結(jié)

以上是生活随笔為你收集整理的JMM 学习笔记的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。