前言

對於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多線程並發鎖和原子操作，你真的了解嗎？