一、原子性

原子性操作指相應的操作是單一不可分割的操作。例如，對int變數count執行count++d操作就不是原子性操作。因為count++實際上可以分解為3個操作：（1）讀取變數count的當前值；（2）拿count的當前值和1做加法運算；（3）將加完後的值賦給count變數。

在多執行緒環境中，非原子操作可能會受其他執行緒的干擾。比如，上述例子如果沒有對相應的程式碼進行同步（Synchronization）處理，則可能出現在執行第2個操作的時候，count變數的值已經被其他執行緒修改過了。當然，synchronized關鍵字可以幫助我們實現原子性操作，以避免這種執行緒間的干擾情況。

synchronized

二、記憶體可見性

  CPU在執行程式碼的時候，為了減少變數訪問的時間消耗可能將程式碼中訪問的變數的值快取到該CPU快取區中，因此，相應的程式碼再次訪問該變數的時候，相應的值可能從CPU快取中而不是主記憶體中讀取的。同樣的，程式碼對這些被快取過的變數的值的修改也可能僅是被寫入CPU快取區，而沒有寫入主記憶體。由於每個CPU都有自己的快取區，因此一個CPU快取區中的內容對於其他CPU而言是不可見的。這就導致了在其他CPU上執行的其他執行緒可能無法“看到”該執行緒對某個變數值的更改。這就是所謂的記憶體可見性。

synchronized關鍵字的另一個作用就是保證了一個執行緒執行臨界區中的程式碼時，所修改的變數值對於稍後執行該臨界區的執行緒來說是可見的。這對於保證多執行緒程式碼的正確性來說非常重要。

而volatile關鍵字也能夠保證記憶體可見性。即一個執行緒對一個採用volatile關鍵字修飾的變數的值的更改，對於其他訪問該變數的執行緒而言總是可見的。也就是說，其他執行緒不會讀到一個“過期”的變數值。因此，有人將volatile關鍵字和synchronized關鍵字所代表的內部鎖做比較，將其稱為輕量級的鎖。這種稱呼其實並不恰當，volatile關鍵字只能保證記憶體可見性，它並不能像synchronized

三、指令重排序

volatile關鍵字的另一個作用是：它禁止了指令重排序（Re-order）。編譯器和CPU為了提高指令的執行效率可能會進行指令重排序，這使得程式碼的實際執行方式可能不是按照我們所認為的方式進行。例如下面的例項變數初始化語句：

private SomeClass someObject = new SomeClass();

上述語句非常簡單：（1）建立類SomeClass 的例項；（2）將類SomeClass 的例項的引用賦給變數someObject 。但是由於指令的重排序作用，這段程式碼的實際執行順序可能是：（1）分配一段用於儲存SomeClass 例項的記憶體空間；（2）將對該記憶體空間的引用賦給變數someObject；（3）建立類SomeClass 的例項。因此，當其他執行緒訪問someObject變數的值時，其得到的僅是指向一段儲存SomeClass 例項的的記憶體空間的引用而已，而該記憶體空間相應的SomeClass 例項的初始化可能尚未完成，這就可能導致一些意想不到的結果。而禁止指令重排序則是可以使得上述程式碼按照我們所期望的順序（正如程式碼所表達的順序）來執行。

禁止指令重排序雖然導致編譯器和CPU無法對一些指令進行可能的優化，但是它某種程度上讓程式碼執行看起來更符合我們的期望。

Volatile、synchronized兩者的區別聯絡

1.volatile本質是在告訴jvm當前變數在暫存器（工作記憶體）中的值是不確定的，需要從主存中讀取；synchronized則是鎖定當前變數，只有當前執行緒可以訪問該變數，其他執行緒被阻塞住。2.volatile僅能使用在變數級別；synchronized則可以使用在變數、方法、和類級別的。3.volatile僅能實現變數的修改可見性，不能保證原子性（執行緒A修改了變數還沒結束時,另外的執行緒B可以看到已修改的值,而且可以修改這個變數,而不用等待A釋放鎖,因為Volatile 變數沒上鎖）；而synchronized則可以保證變數的修改可見性和原子性。4.volatile不會造成執行緒的阻塞；synchronized可能會造成執行緒的阻塞和上下文切換。5.volatile標記的變數不會被編譯器優化；synchronized標記的變數可以被編譯器優化。

6.在使用volatile關鍵字時要慎重，並不是只要簡單型別變數使用volatile修飾，對這個變數的所有操作都是原子操作。當變數的值由自身決定時，如n=n+1、n++ 等，volatile關鍵字將失效。只有當變數的值和自身無關時對該變數的操作才是原子級別的，如n = m + 1，這個就是原級別的。所以在使用volatile關鍵時一定要謹慎，如果自己沒有把握，可以使用synchronized來代替volatile。

7.“鎖是昂貴的”，謹慎使用鎖機制。

四、順序一致性

資料競爭與順序一致性保證

當程式未正確同步時，就會存在資料競爭。java記憶體模型規範對資料競爭的定義如下：

• 在一個執行緒中寫一個變數，
• 在另一個執行緒讀同一個變數，
• 而且寫和讀沒有通過同步來排序。

當代碼中包含資料競爭時，程式的執行往往產生違反直覺的結果（前一章的示例正是如此）。如果一個多執行緒程式能正確同步，這個程式將是一個沒有資料競爭的程式。

JMM對正確同步的多執行緒程式的記憶體一致性做了如下保證：

• 如果程式是正確同步的，程式的執行將具有順序一致性（sequentially consistent）--即程式的執行結果與該程式在順序一致性記憶體模型中的執行結果相同（馬上我們將會看到，這對於程式設計師來說是一個極強的保證）。這裡的同步是指廣義上的同步，包括對常用同步原語（lock，volatile和final）的正確使用。

順序一致性記憶體模型

順序一致性記憶體模型是一個被電腦科學家理想化了的理論參考模型，它為程式設計師提供了極強的記憶體可見性保證。順序一致性記憶體模型有兩大特性：

• 一個執行緒中的所有操作必須按照程式的順序來執行。
• （不管程式是否同步）所有執行緒都只能看到一個單一的操作執行順序。在順序一致性記憶體模型中，每個操作都必須原子執行且立刻對所有執行緒可見。

順序一致性記憶體模型為程式設計師提供的檢視如下：

在概念上，順序一致性模型有一個單一的全域性記憶體，這個記憶體通過一個左右擺動的開關可以連線到任意一個執行緒。同時，每一個執行緒必須按程式的順序來執行記憶體讀/寫操作。從上圖我們可以看出，在任意時間點最多隻能有一個執行緒可以連線到記憶體。當多個執行緒併發執行時，圖中的開關裝置能把所有執行緒的所有記憶體讀/寫操作序列化。

為了更好的理解，下面我們通過兩個示意圖來對順序一致性模型的特性做進一步的說明。

假設有兩個執行緒A和B併發執行。其中A執行緒有三個操作，它們在程式中的順序是：A1->A2->A3。B執行緒也有三個操作，它們在程式中的順序是：B1->B2->B3。

假設這兩個執行緒使用監視器來正確同步：A執行緒的三個操作執行後釋放監視器，隨後B執行緒獲取同一個監視器。那麼程式在順序一致性模型中的執行效果將如下圖所示：

現在我們再假設這兩個執行緒沒有做同步，下面是這個未同步程式在順序一致性模型中的執行示意圖：

未同步程式在順序一致性模型中雖然整體執行順序是無序的，但所有執行緒都只能看到一個一致的整體執行順序。以上圖為例，執行緒A和B看到的執行順序都是：B1->A1->A2->B2->A3->B3。之所以能得到這個保證是因為順序一致性記憶體模型中的每個操作必須立即對任意執行緒可見。

但是，在JMM中就沒有這個保證。未同步程式在JMM中不但整體的執行順序是無序的，而且所有執行緒看到的操作執行順序也可能不一致。比如，在當前執行緒把寫過的資料快取在本地記憶體中，且還沒有重新整理到主記憶體之前，這個寫操作僅對當前執行緒可見；從其他執行緒的角度來觀察，會認為這個寫操作根本還沒有被當前執行緒執行。只有當前執行緒把本地記憶體中寫過的資料重新整理到主記憶體之後，這個寫操作才能對其他執行緒可見。在這種情況下，當前執行緒和其它執行緒看到的操作執行順序將不一致。

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

下面我們對前面的示例程式ReorderExample用監視器來同步，看看正確同步的程式如何具有順序一致性。

請看下面的示例程式碼：

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;
        ……
    }
}
}

上面示例程式碼中，假設A執行緒執行writer()方法後，B執行緒執行reader()方法。這是一個正確同步的多執行緒程式。根據JMM規範，該程式的執行結果將與該程式在順序一致性模型中的執行結果相同。下面是該程式在兩個記憶體模型中的執行時序對比圖：

在順序一致性模型中，所有操作完全按程式的順序序列執行。而在JMM中，臨界區內的程式碼可以重排序（但JMM不允許臨界區內的程式碼“逸出”到臨界區之外，那樣會破壞監視器的語義）。JMM會在退出監視器和進入監視器這兩個關鍵時間點做一些特別處理，使得執行緒在這兩個時間點具有與順序一致性模型相同的記憶體檢視（具體細節後文會說明）。雖然執行緒A在臨界區內做了重排序，但由於監視器的互斥執行的特性，這裡的執行緒B根本無法“觀察”到執行緒A在臨界區內的重排序。這種重排序既提高了執行效率，又沒有改變程式的執行結果。

從這裡我們可以看到JMM在具體實現上的基本方針：在不改變（正確同步的）程式執行結果的前提下，儘可能的為編譯器和處理器的優化開啟方便之門。

未同步程式的執行特性

對於未同步或未正確同步的多執行緒程式，JMM只提供最小安全性：執行緒執行時讀取到的值，要麼是之前某個執行緒寫入的值，要麼是預設值（0，null，false），JMM保證執行緒讀操作讀取到的值不會無中生有（out of thin air）的冒出來。為了實現最小安全性，JVM在堆上分配物件時，首先會清零記憶體空間，然後才會在上面分配物件（JVM內部會同步這兩個操作）。因此，在以清零的記憶體空間（pre-zeroed memory）分配物件時，域的預設初始化已經完成了。

JMM不保證未同步程式的執行結果與該程式在順序一致性模型中的執行結果一致。因為未同步程式在順序一致性模型中執行時，整體上是無序的，其執行結果無法預知。保證未同步程式在兩個模型中的執行結果一致毫無意義。

和順序一致性模型一樣，未同步程式在JMM中的執行時，整體上也是無序的，其執行結果也無法預知。同時，未同步程式在這兩個模型中的執行特性有下面幾個差異：

1. 順序一致性模型保證單執行緒內的操作會按程式的順序執行，而JMM不保證單執行緒內的操作會按程式的順序執行（比如上面正確同步的多執行緒程式在臨界區內的重排序）。這一點前面已經講過了，這裡就不再贅述。
2. 順序一致性模型保證所有執行緒只能看到一致的操作執行順序，而JMM不保證所有執行緒能看到一致的操作執行順序。這一點前面也已經講過，這裡就不再贅述。
3. JMM不保證對64位的long型和double型變數的讀/寫操作具有原子性，而順序一致性模型保證對所有的記憶體讀/寫操作都具有原子性。

第3個差異與處理器匯流排的工作機制密切相關。在計算機中，資料通過匯流排在處理器和記憶體之間傳遞。每次處理器和記憶體之間的資料傳遞都是通過一系列步驟來完成的，這一系列步驟稱之為匯流排事務（bus transaction）。匯流排事務包括讀事務（read transaction）和寫事務（write transaction）。讀事務從記憶體傳送資料到處理器，寫事務從處理器傳送資料到記憶體，每個事務會讀/寫記憶體中一個或多個物理上連續的字。這裡的關鍵是，匯流排會同步試圖併發使用匯流排的事務。在一個處理器執行匯流排事務期間，匯流排會禁止其它所有的處理器和I/O裝置執行記憶體的讀/寫。下面讓我們通過一個示意圖來說明匯流排的工作機制：

如上圖所示，假設處理器A，B和C同時向匯流排發起匯流排事務，這時匯流排仲裁（bus arbitration）會對競爭作出裁決，這裡我們假設匯流排在仲裁後判定處理器A在競爭中獲勝（匯流排仲裁會確保所有處理器都能公平的訪問記憶體）。此時處理器A繼續它的匯流排事務，而其它兩個處理器則要等待處理器A的匯流排事務完成後才能開始再次執行記憶體訪問。假設在處理器A執行匯流排事務期間（不管這個匯流排事務是讀事務還是寫事務），處理器D向匯流排發起了匯流排事務，此時處理器D的這個請求會被匯流排禁止。

匯流排的這些工作機制可以把所有處理器對記憶體的訪問以序列化的方式來執行；在任意時間點，最多隻能有一個處理器能訪問記憶體。這個特性確保了單個匯流排事務之中的記憶體讀/寫操作具有原子性。

在一些32位的處理器上，如果要求對64位資料的讀/寫操作具有原子性，會有比較大的開銷。為了照顧這種處理器，java語言規範鼓勵但不強求JVM對64位的long型變數和double型變數的讀/寫具有原子性。當JVM在這種處理器上執行時，會把一個64位long/ double型變數的讀/寫操作拆分為兩個32位的讀/寫操作來執行。這兩個32位的讀/寫操作可能會被分配到不同的匯流排事務中執行，此時對這個64位變數的讀/寫將不具有原子性。

當單個記憶體操作不具有原子性，將可能會產生意想不到後果。請看下面示意圖：

如上圖所示，假設處理器A寫一個long型變數，同時處理器B要讀這個long型變數。處理器A中64位的寫操作被拆分為兩個32位的寫操作，且這兩個32位的寫操作被分配到不同的寫事務中執行。同時處理器B中64位的讀操作被拆分為兩個32位的讀操作，且這兩個32位的讀操作被分配到同一個的讀事務中執行。當處理器A和B按上圖的時序來執行時，處理器B將看到僅僅被處理器A“寫了一半“的無效值。

參考文獻

五、鎖

六、final

        根據程式上下文環境，Java關鍵字final有“這是無法改變的”或者“終態的”含義，它可以修飾非抽象類、非抽象類成員方法和變數。你可能出於兩種理解而需要阻止改變：設計或效率。

        final類不能被繼承，沒有子類，final類中的方法預設是final的。

        final方法不能被子類的方法覆蓋，但可以被繼承。

        final成員變量表示常量，只能被賦值一次，賦值後值不再改變。

        final不能用於修飾構造方法。

        注意：父類的private成員方法是不能被子類方法覆蓋的，因此private型別的方法預設是final型別的。

1、final類

，預設都是final的。在設計類時候，如果這個類不需要有子類，類的實現細節不允許改變，並且確信這個類不會載被擴充套件，那麼就設計為final類。

2、final方法

        如果一個類不允許其子類覆蓋某個方法，則可以把這個方法宣告為final方法。

        使用final方法的原因有二：

        第一、把方法鎖定，防止任何繼承類修改它的意義和實現。

        第二、高效。編譯器在遇到呼叫final方法時候會轉入內嵌機制，大大提高執行效率。

 例如：