在程式開發中，有時需要延遲一些高開銷的物件初始化操作，並且只有在使用這些物件時才進行初始化，此時可以採用雙重檢查鎖定來延遲物件初始化操作。雙重檢查鎖定是設計用來減少並發系統中競爭和同步開銷的一種軟體設計模式，在普通單例模式的基礎上，先判斷物件是否已經被初始化，再決定要不要加鎖。儘管雙重檢查鎖定解決了普通單例模式的在多線程環境中易出錯和線程不安全的問題，但仍存在一些隱患。以下以JAVA語言原始碼為例，分析雙重檢查鎖定缺陷產生的原因以及修復方法。
#雙重檢查鎖定在單執行緒環境中並無影響，在多執行緒環境下，由於執行緒隨時會互相切換執行，在指令重排的情況下，物件未實例化完全，導致程式呼叫出錯。
範例源自於Samate Juliet Test Suite for Java v1.3 (https://samate.nist.gov/SARD/testsuite.php )，原始檔名：CWE609_Double_Checked_Locking__Servlet_01.java。
#上述程式碼行23行-38行，程式先判斷stringBad 是否為null，如果不是則直接傳回該String 對象，這樣避免了進入synchronized 區塊所需花費的資源。當 stringBad 為 null 時，使用 synchronized 關鍵字在多執行緒環境中避免多次建立 String 物件。在程式碼實際運行時，以上程式碼仍然可能發生錯誤。
對於第33行，建立 stringBad 物件和賦值運算是分兩步驟執行的。但 JVM 不保證這兩個操作的先後順序。當指令重新排序後，JVM 會先賦值指向了記憶體位址，然後再初始化 stringBad 物件。如果此時存在兩個線程，則兩個線程同時進入了第27行。線程1首先進入了 synchronized 區塊，由於 stringBad 為 null，所以它執行了第33行。當JVM 對指令進行了重排序，JVM 先分配了實例的空白內存，並賦值給stringBad，但這時stringBad 物件還未實例化，然後線程1離開了synchronized 區塊。當線程2進入 synchronized 區塊時，由於 stringBad 此時不是 null ,直接傳回了未被實例化的物件（僅有記憶體位址值，物件實際未初始化）。後續執行緒2呼叫程式對 stringBad 物件進行操作時，此時的物件未被初始化，於是錯誤發生。
使用360程式碼衛兵對上述範例程式碼進行偵測，可以檢出「雙重檢查鎖定」缺陷，顯示等級為中。在程式碼行第27行報出缺陷，如圖1所示：
圖1：「雙重檢查鎖定」的偵測範例
volatile 關鍵字來對單例變數 stringBad 進行修飾。 volatile 作為指令關鍵字確保指令不會因編譯器的最佳化而省略，且要求每次直接讀值。 volatile 關鍵字就可以從語意解決這個問題，值得關注的是volatile 的禁止指令重排序優化功能在Java 1.5 後才得以實現，因此1.5 前的版本仍然是不安全的，即使使用了volatile 關鍵字。 使用360程式碼衛兵對修復後的程式碼進行偵測，可以看到已不存在「雙重檢查鎖定」缺陷。如圖2：
要避免雙重檢查鎖定，需要注意以下幾點：
（1）使用volatile 關鍵字避免指令重新排序，但這個解決方案需要JDK5 或更高版本，因為從JDK5 開始使用新的JSR-133 記憶體模型規範，這個規範增強了volatile 的語意。
（2）基於類別初始化的解決方案。
JVM在類別的初始化階段（即在Class被載入後，且被執行緒使用之前），會執行類別的初始化。在執行類別的初始化期間，JVM會去取得一個鎖。這個鎖可以同步多個執行緒對同一個類別的初始化。
以上是如何用JAVA語言分析雙重檢查鎖定的詳細內容。更多資訊請關注PHP中文網其他相關文章！
