前言
對於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線程鎖機制有一個比較詳細的分析。