說明

前天分享了一篇關於阿里的“Java常見疑惑和陷阱”的文章，有人說這個很早就有了，可能我才注意到，看完之後發現內容非常不錯，有幾個我也是需要停頓下想想，如果後續有機會我錄製一個視訊把這個ppt裡面的所有內容，根據我的理解和知道的給大家分享一遍。

如果你之前還沒有看過建議好好看一遍：Java常見疑惑和陷阱，如果你需要獲取完整ppt，可以在公號對話方塊回覆： “PPT” 即可獲取完整檔案，只要你發現你看到裡面知識點的時候，你需要思考一會，那麼就表示你還不太熟悉，你應該去補補相關的基礎知識了。

題目

我個人一直認為： 網路、併發相關的知識，相對其他一些程式設計知識點更難一些，主要是不好除錯並且涉及內容太多 ！

所以今天就取一篇併發相關的內容分享下，我相信大家認真看完會有收穫的。

大家可以先看看這個問題，看看這個是否有問題呢？ 那裡有問題呢？

如果你在這個問題上面停留超過5s的話，那麼表示你對這塊某些知識還有點模糊，需要再鞏固下，下面我們一起來分析下！

結論

多執行緒併發的同時進行set、get操作，A執行緒呼叫set方法，B執行緒並不一定能對這個改變可見！！！

分析

這個類非常簡單，裡面有一個屬性，有2個方法：get、set方法，一個用來設定屬性值，一個用來獲取屬性值，在設定屬性方法上面加了synchronized。

隱式資訊： 多執行緒併發的同時進行set、get操作，A執行緒呼叫set方法，B執行緒可以裡面感知到嗎？？？

說到這裡，問題就變成了synchronized在剛剛說的上下文下面能否保證可見性！！！

關鍵詞synchronized的用法

• 指定加鎖物件:對給定物件加鎖，進入同步程式碼前需要獲得給定物件的鎖。
• 直接作用於例項方法:相當於對當前例項加鎖，進入同步程式碼前要獲得當前例項的鎖。
• 直接作用於靜態方法:相當於對當前類加鎖，進入同步程式碼前要獲得當前類的鎖。

synchronized它的工作就是對需要同步的程式碼加鎖，使得每一次只有一個執行緒可以進入同步塊（其實是一種悲觀策略）從而保證執行緒之間得安全性。

從這裡我們可以知道，我們需要分析的屬於第二類情況，也就是說多個執行緒如果同時進行set方法的時候，由於存在鎖，所以會一個一個進行set操作，並且是執行緒安全的，但是get方法並沒有加鎖，表示假如A執行緒在進行set的同時B執行緒可以進行get操作。並且可以多個執行緒同時進行get操作，但是同一時間最多隻能有一個set操作。

Java 記憶體模型 happens-before原則

JSR-133 記憶體模型使用 happens-before 的概念來闡述操作之間的記憶體可見性。在 JMM 中，如果一個操作執行的結果需要對另一個操作可見，那麼這兩個操作之間必須要存在 happens-before 關係。這裡提到的兩個操作既可以是在一個執行緒之內，也可以是在不同執行緒之間。

與程式設計師密切相關的 happens-before 規則如下：

• 程式順序規則：一個執行緒中的每個操作，happens-before 於該執行緒中的任意後續操作。
• 監視器鎖規則：對一個監視器的解鎖，happens-before 於隨後對這個監視器的加鎖。
• volatile 變數規則：對一個 volatile 域的寫，happens-before 於任意後續對這個 volatile 域的讀。
• 傳遞性：如果 A happens-before B，且 B happens-before C，那麼 A happens-before C。

注意，兩個操作之間具有 happens-before 關係，並不意味著前一個操作必須要在後一個操作之前執行！happens-before 僅僅要求前一個操作（執行的結果）對後一個操作可見，且前一個操作按順序排在第二個操作之前（the first is visible to and ordered before the second）。

其中有監視器鎖規則：對一個監視器的解鎖，happens-before 於隨後對這個監視器的加鎖。這一條，僅僅只是針對synchronized的set方法，而對於get並沒有這方面的說明。

其實在這種上下文下面一個synchronized的set方法，一個普通的get方法，a執行緒呼叫set方法，b執行緒並不一定能對這個改變可見！

更多Java記憶體模型記憶體歡迎檢視：深入理解 Java 記憶體模型，寫的非常詳細，建議多讀幾遍！！！

volatile

volatile可見性

前面happens-before原則就提到：volatile 變數規則：對一個 volatile 域的寫，happens-before 於任意後續對這個 volatile 域的讀。 volatile從而保證了多執行緒下的可見性！！！

volatile 禁止記憶體重排序

下面是 JMM 針對編譯器制定的 volatile 重排序規則表：

為了實現 volatile 的記憶體語義，編譯器在生成位元組碼時，會在指令序列中插入記憶體屏障來禁止特定型別的處理器重排序。

下面是基於保守策略的 JMM 記憶體屏障插入策略：

• 在每個 volatile 寫操作的前面插入一個 StoreStore 屏障。
• 在每個 volatile 寫操作的後面插入一個 StoreLoad 屏障。
• 在每個 volatile 讀操作的後面插入一個 LoadLoad 屏障。
• 在每個 volatile 讀操作的後面插入一個 LoadStore 屏障。

下面是保守策略下，volatile 寫操作 插入記憶體屏障後生成的指令序列示意圖：

下面是在保守策略下，volatile 讀操作 插入記憶體屏障後生成的指令序列示意圖：

上述 volatile 寫操作和 volatile 讀操作的記憶體屏障插入策略非常保守。在實際執行時，只要不改變 volatile 寫-讀的記憶體語義，編譯器可以根據具體情況省略不必要的屏障。

更多Java記憶體模型記憶體歡迎檢視：深入理解 Java 記憶體模型，寫的非常詳細，建議多讀幾遍！！！

雙重檢查鎖實現單例中就需要用到這個特性！！！

模擬

通過上面的分析，其實這個題目涉及到的內容都提到了，並且進行了解答。

雖然你知道的原因，但是想模擬並不是一件容易的事情！，下面我們來模擬看看效果：

public class ThreadSafeCache {
    int result;

    public int getResult() {
        return result;
    }

    public synchronized void setResult(int result) {
        this.result = result;
    }

    public static void main(String[] args) {
        ThreadSafeCache threadSafeCache = new ThreadSafeCache();

        for (int i = 0; i < 8; i++) {
            new Thread(() -> {
                int x = 0;
                while (threadSafeCache.getResult() < 100) {
                    x++;
                }
                System.out.println(x);
            }).start();
        }

        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        threadSafeCache.setResult(200);
    }
}

效果：

程式會一直卡在這邊不動，表示set修改的200，get方法並不可見！！！

新增volatile 關鍵詞觀察效果

其例項子中synchronized關鍵字可以去掉，僅僅用volatile即可。

效果：

程式碼很快正常結束了！

結論：多執行緒併發的同時進行set、get操作，A執行緒呼叫set方法，B執行緒並不一定能對這個改變可見！！！，上面的程式碼中，如果對get方法也加synchronized也是可見的，還是happens-before的監視器鎖規則：對一個監視器的解鎖，happens-before 於隨後對這個監視器的加鎖。，只是volatile比synchronized更輕量級，所以本例直接用volatile。但是對於符合非原子操作i++這裡還是不行的還是需要synchronized。

更多Java記憶體模型記憶體歡迎檢視：深入理解 Java 記憶體模型，寫的非常詳細，建議多讀幾遍！！！

建議好好看看Java常見疑惑和陷阱，裡面有很多很優秀的東西，如果你需要獲取完整ppt，可以在公號對話方塊回覆： “PPT” 即可獲取完整檔案！

如果讀完覺得有收穫的話，歡迎點贊、關注、加公眾號【匠心零度】，查閱更多精彩歷史！！！
)