Java多線程並發鎖和原子操作，你真的瞭解嗎？

標籤：img   方式   ddd   cin   也會   for   ++   控制   tor   

 前言        

        對於Java多線程，接觸最多的莫過於使用synchronized，這個簡單易懂，但是這synchronized並非效能最優的。今天我就簡單介紹一下幾種鎖。可能我下面講的時候其實很多東西不會特別深刻，最好的方式是自己做實驗，把各種情境在代碼中實驗一下，這樣發發現很多細節。

volatile

        作為Java中的輕量級鎖，當多線程中一個線程操作後可以保證其他線程可見，也就是書上所說的“可見度”，另外一個就是“重排序”。所謂重排序指的是JVM對指令的最佳化。很多人可能在實際實驗中發現好像不是如此，最後的例子我也會說明這一點。

synchronized

        這個作為Java中“重量級”的安全執行緒機制被大家所熟知，這個就不在這裡做解釋了。

java.util.concurrent.locks.ReentrantLock        java.util.concurrent.中是JDK1.5中出的對於一些並行作業的類庫，其中包括很多同學很喜歡的原子類，比如說AtomicInteger。它裡面原理就是一個CAS，這裡就不做過多的闡述，有興趣的可以看看源碼。

 

       好，說一下ReentrantLock，這個鎖主要是能顯示的添加鎖和釋放鎖，好處是更加靈活，能夠更加準確的控制鎖，也能確保系統的穩定，比如說“重連”。後面代碼會有使用到。 

 實際情境

       上面介紹完了幾種鎖，下面用具體的代碼來看看幾種鎖的實際用法，以及各種表現形式。代碼有點長，這裡最好自己實驗一下，然後看看結果，並思考這個結果。

輸出結果：

            i>>>>>381890

            vi>>>>>353610

            ai>>>>>400000

            si>>>>>392718

            ri>>>>>392658

 從上面的輸出結果來看真是讓人大感意外：只有原子操作AtomicInteger的結果保證了多線程的安全性，而其他不管是用輕量級的volatile還是重量級的synchronized都沒有達到我們想要的效果。這也讓我產生了大在的懷疑。難道問題真的這麼蹊蹺？

       從這裡不難看出除了AtomicInteger用的是其自己的方法而其他都是用到了Java的文法糖++操作。而這讓我想起了++操作並非原子操作，而可能在其中間操作導致了其他線程對其他進行了修改，雖然同樣的問題我在《Think in Java》中也找到可以佐證的例子。這裡有一個問題就是synchronized：因為我對si已經加了synchronized操作，但是輸出的結果令人意外，難道還會有問題？這讓我想把這段代碼編譯成位元組碼的衝動。好吧，下面看位元組碼（這裡我單獨把synchronized這一段操作抽出來，作為分析，其他幾個就算了，不然編譯後的位元組碼有點多）

      為了方便看，先貼出原始碼

下面是位元組碼，為了節省篇幅，一些不重要的部分我將不貼出

從這裡一看從monitorenter進入安全區到monitorexit出安全區沒有發現si是處於中間狀態的，那又是在哪出的問題呢？這裡簡單說一下，歸根結底仍然是（++）操作非原子操作，可是很多人疑惑了，這裡不是加鎖了嗎？廢話不多說，在我的深入探析Java線程鎖機制有一個比較詳細的分析。

 

Java多線程並發鎖和原子操作，你真的瞭解嗎？