關于synchronized

眾所周知，JAVA中最簡單的加鎖方法是用關鍵字synchronized，我們可以使用這個關鍵字將一個方法變成線程安全的，也可以將一個代碼塊變成線程安全的，這樣子我們不需要再擔心多線程同時執行到這段代碼會引發的并發問題。同時配合方法wait，notify和notifyall可以很好的實現多線程之間的協作，比如某個線程因為需要等待一些資源，于是調用wait方法將自己設置為waiting狀態，其他線程釋放或生產這個線程需要的資源的時候需要通知這個線程（notify）將其喚醒，或者通知所有等待當前資源的線程（notifyall）。

然而當功能完成之后我們似乎并不滿足于此，于是我們開始考慮這么做的代價是什么，是否可以做的更好。

先說說這么做（使用synchronized）的代價是什么，當多個線程請求臨界資源的時候只能有一個線程得到滿足，那么其他的線程會做什么呢，他們會被阻塞，直到被通知（notify/notifyall）又有資源的時候才被喚醒進行再一次的鎖爭用，而后往復的是又只有一個線程能被得到滿足，其他的線程繼續進入阻塞狀態，而這個時候可能會有不斷的增加爭用線程。性能損耗的關鍵點在于線程的阻塞操作是由操作系統來完成的，在Linux系統下是由pthread_mutex_lock函數來完成。線程被阻塞之后便進入了內核調度態，這個過程發生了操作系統將保存用戶態的上下文進入內核態，這也就是常說的上下文切換，上下文切換代價大，在于操作系統需要將當前線程執行上下文內容（包括堆棧、寄存器等存儲的內容）的保存以便之后線程切換回來時候再進行現場恢復。

上面可以看出使用synchronized的代價是什么了吧，當競爭激烈的時候會引起頻繁的操作系統上下文切換，從而影響系統的性能。下面再來講講自旋鎖。

自旋鎖的原理

自旋鎖是對線程阻塞的一種優化，他的原理簡單的說就是當線程爭用鎖失敗的時候不立即進入阻塞狀態，而是再等一會，因為對于執行時間短的代碼這一會可能就會釋放鎖，而線程就不需要進行一次阻塞與喚醒。等待操作就是讓線程多執行幾個空指令，至于等待多久這跟具體的處理器實現有關，也有可能處理器根本不支持自旋鎖，具體實現的時候我們可以設置一個臨界值，當超過了這個臨界值之后我們就不自旋了，就乖乖進入阻塞狀態吧。這種優化對于執行時間短的代碼是很有效的。synchronized使用自旋鎖的時機是線程進入等待隊列即阻塞的前一步。

關于偏向鎖

偏向鎖是java6提供的一種功能，主要是對無競爭條件下的對加鎖代碼執行的優化，得到優化的地方是省去了對等待隊列的更新操作。在競爭條件下，獲取鎖失敗的線程會被放入等待隊列，這個隊列的更新操作是通過CAS指令來完成的。對于那么一段本部應該被加鎖的代碼被加了鎖，我們認為每次執行這段被加了鎖的代碼的時候更新等待隊列的操作并不是必要的，而CAS操作會延遲本地代碼的執行，因此偏向鎖是用于優化這個問題的。

關于Lock

Lock是JAVA5增加的內容，在JCU（java.util.concurrent.locks）包下面，作者是并發大師Doug Lea。JCU包提供了很多封裝的鎖，包括常用的ReentrantLock和ReadWriteLock。這些所其實都是依賴java.util.concurrent.AbstractQueuedSynchronizer這個類來實現的，這個類有個簡寫的名字叫AQS，對這就是著名的AQS。

關于Lock，先說說線程獲取Lock鎖的時候會引起哪些事件呢。首先AQS是依賴一個被volatile修飾的int變量來標識當前鎖的狀態的，為0的時候代表當前鎖不被任何線程擁有，當線程拿到這個鎖的時候會通過CAS操作修改state的狀態，那么對于爭用失敗的線程AQS會怎么辦呢，AQS內部維護了一個等待隊列，這個隊列是純JAVA實現的，其實現也是非常巧妙的，多線程在通過CAS來獲取自己在隊列中的位置，同時隊列中的線程狀態也是阻塞狀態，遇到阻塞就頭疼了，上面已經介紹過阻塞會帶來的性能問題。在源碼中我們可以看到的是AQS通過LockSupport（LockSupport底層依賴Unsafe）將線程阻塞，關于LockSupport我有一篇文章介紹的，其功能是用來代替wait和notity/notifyall的，更好的地方是LockSupport對park方法和unpark方法的調用沒有先后的限制，而notify/notifyall必須在wait調用之后調用。盡管如此，這一切并沒有阻止線程進入阻塞狀態，我有點失望。

無鎖時代

講到無鎖，必然是Disruptor并發框架，Disruptor底層依賴一個RingBuffer來進行線程之間的數據交換，無鎖在于在并發條件下，多線程對RingBuffer的讀和寫不會涉及到鎖，然而因為RingBuffer滿或者RingBuffer中沒有可消費內容引發的線程等待，那就要另當別論了。簡單幾句介紹下無鎖原理，RingBuffer維護者可讀和可寫的指針，也叫游標，它指向生產者或消費者需要寫或讀的位置，而對于指針的更新是由CAS來完成的，這個過程中我們不需要加鎖/解鎖的過程。

后記：

JAVA鎖方面的知識主要是要搞清楚不同的鎖的優點與缺點，深入到操作系統層的實現機制與不同場景中對應用的性能影響。本文簡單的擼了一下JAVA鎖從synchronized到無鎖的發展以及一些鎖的簡單原理，主要是拋磚引玉吧，因為介紹的比較簡單，對于文中提到的知識不知道的同學可以深入了解，我相信你會很有收獲。有些實現的原理介紹可能就一句話，但是實際實現起來是蠻復雜的，需要考慮到的東西是我們沒有寫過所不能考慮到的。到這里，如果你的項目中用到了多線程并發，你是否會考慮使用無鎖模型來優化你項目中多線程之間的通信呢。