關(guān)于synchronized

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

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

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

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

自旋鎖的原理

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

關(guān)于偏向鎖

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

關(guān)于Lock

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

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

無鎖時代

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

后記：

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