今天看《Java併發程式設計實戰》看到安全釋出的問題中final修飾符的作用，一時半會沒有看明白，查了一些資料才懂了一些深層次的原因，所以做一些記錄。

首先我們來看一下書中的例子和描述

//不安全的釋出
public Holder holder;

public void initialize() {
    holder = new Holder(42);
}

這段是一個不安全的物件釋出，書上的描述是“由於存在可見性問題，其他執行緒看到的Holder物件將處於不一致的狀態，即便在該物件的建構函式中已經正確地構建了不變性條件。這種不正確的釋出導致其他執行緒看到尚未建立完成的物件。”這段我讀到的時候的理解就是holder由於是完全可見的，那有可能沒有執行建構函式就被使用了，自然會出錯嘛…可是越往後讀越證明，我想的太天真了。

隨後書中舉了一個簡單的例子證明上面這段程式碼是不安全的釋出

public class Holder {
  private int n;

  public Holder(int n) { this.n = n; }

  public void assertSanity() {
    if (n != n)
      throw new AssertionError("This statement is false.");
  }
}

書上是這麼描述問題的，另一個執行緒呼叫assertSanity時有可能丟擲異常，看到這裡我覺得哎呀我想對了，你的holder是個空引用之類的不可預知狀態，當然會報錯了！可是當看到書中的解釋，我就懵逼了…

“由於沒有使用同步來確保Holder物件對其他執行緒可見，因此將Holder稱為“未被正確釋出”。在未被正確釋出的物件中存在兩個問題。
首先 ，除了釋出物件的執行緒外，其他執行緒可以看到的 Holder域是一個失效值 ，因此將看到一個空引用或者之前的舊值。
然而 ，更糟糕的情況是，執行緒看到Holder引用的值是最新的，但Holder狀態的值卻是失效的。情況變得更加不可預測的是，某個執行緒在第一次讀取域時得到失效值，而再次讀取這個域時會得到一個更新值，這也是assertSainty丟擲AssertionError的原因。”

上面說了兩個問題，第一種就是我們設想的最簡單的情況（還是有悟性的哈哈），可當我看到第二種，我就懵逼了，特別是這句”執行緒看到Holder引用的值是最新的，但Holder狀態的值卻是失效的“，我的引用都有效了，狀態為何是失效的呢？（覺得簡單的大牛不要嘲笑我，一開始看到這裡真的懵）

看不懂歸看不懂，抱著往下看看我說不定就明白了的心態我硬著頭皮往下看，可誰知，越往下看越懵逼，書中說了一種解決問題的方式：“如果將n宣告為final型別，那麼Holder將不可變，那麼即使Holder沒有被正確的釋出，在assertSanity中也不會丟擲異常”，這……本來就不知道為何會又第二種異常，這個解決方法就更不明白了，這就加了個小小的final，就不會有問題了，這簡直是一環套一環的懵逼。

好了我的疑惑已經說的很明白了：

第一、我不知道為什麼在holder引用最新的情況下會報出異常

第二、我不知道為什麼加了final修飾n之後就不會出現問題

下面我就開始解惑了

第一、為什麼在holder引用最新的情況下會報出異常

我們來看一下我們認為的過程，

    holder = new Holder(42);

我們認為holder是最新的，就意味著holder指向了我們所建立的新的物件，也就是n為42的物件對吧，既然引用已經指向了，那我呼叫holder的函式難道還會有問題嘛？這裡這個問題在我前一篇講單例模式在併發中的實現的部落格中已經提到了，我們認為的執行過程是怎麼樣的呢？ （1）給Holder物件分配記憶體 （2）呼叫Holder的建構函式，也就是給n賦值的過程，初始化了成員欄位 （3）將holder引用指向我們分配的記憶體空間

這就是這句程式碼做的基本步驟，我們認為既然第3步已經執行了（holder引用已經指向最新了），那1、2步肯定已經完成了，可是，在JVM自身的效能優化中，是允許這個順序亂序執行的，也就是說，它不能保證執行的順序是1、2、3，也有可能是1、3、2等等很多種情況，這就是問題所在，假設執行了1、3，這是引用已經是最新的了，但2的建構函式沒有執行，那你的物件的狀態值就是失效的，就是說你的n是失效值，當這種偶然的情況出現，另一個執行緒呼叫assertSanity自然會報出異常，這就解釋了為什麼holder引用最新的情況下會報出異常。

第二、為什麼加了final修飾n之後就不會出現問題

知道了上面程式碼的問題所在，我們就可以來了解一下final的作用，javamex上也有一篇“Thread-safety with the Java final keyword”，其中有一段對於final作用的解釋是這麼說的

“The final field is a means of what is sometimes called safe publication . Here, "publication" of an object means creating it in one thread and then having that newly-created object be referred to by another thread at some point in the future. When the JVM executes the constructor of your object, it must store values into the various fields of the object, and store a pointer to the object data. As in any other case of data writes, these accesses can potentially occur out of order, and their application to main memory can be delayed and other processors can be delayed unless you take special steps to combat this. In particular, the pointer to the object data could be stored to main memory and accessed before the fields themselves have been committed (this can happen partly because of compiler ordering: if you think about how you'd write things in a low-level language such as C or assembler, it's quite natural to store a pointer to a block of memory, and then advance the pointer as you're writing data to that block). And this in turn could lead to another thread seeing the object in an invalid or partially constructed state.
    final prevents this from happening: if a field is final , it is part of the JVM specification that it must effectively ensure that, once the object pointer is available to other threads, so are the correct values of that object's final fields.”

大體的意思很簡單，對於含有final域的物件，JVM必須保證對物件的初始引用在建構函式之後執行，不能亂序執行（out of order），也就是可以保證一旦你得到了引用，final域的值都是完成了初始化的，也就是書中所說的“初始化安全性”的保證。這樣一來，我們就可以理解為什麼上面的問題就可以被解決了，JVM保證了不會亂序執行，自然也不會出現問題。