關(guān)于synchronized

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

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

先說說這么做（使用synchronized）的代價是什么，當(dāng)多個線程請求臨界資源的時候只能有一個線程得到滿足，那么其他的線程會做什么呢，他們會被阻塞，直到被通知（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)需要將當(dāng)前線程執(zhí)行上下文內(nèi)容（包括堆棧、寄存器等存儲的內(nèi)容）的保存以便之后線程切換回來時候再進行現(xiàn)場恢復(fù)。

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

自旋鎖的原理

自旋鎖是對線程阻塞的一種優(yōu)化，他的原理簡單的說就是當(dāng)線程爭用鎖失敗的時候不立即進入阻塞狀態(tài)，而是再等一會，因為對于執(zhí)行時間短的代碼這一會可能就會釋放鎖，而線程就不需要進行一次阻塞與喚醒。等待操作就是讓線程多執(zhí)行幾個空指令，至于等待多久這跟具體的處理器實現(xiàn)有關(guān)，也有可能處理器根本不支持自旋鎖，具體實現(xiàn)的時候我們可以設(shè)置一個臨界值，當(dāng)超過了這個臨界值之后我們就不自旋了，就乖乖進入阻塞狀態(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變量來標(biāo)識當(dāng)前鎖的狀態(tài)的，為0的時候代表當(dāng)前鎖不被任何線程擁有，當(dāng)線程拿到這個鎖的時候會通過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ā)的線程等待，那就要另當(dāng)別論了。簡單幾句介紹下無鎖原理，RingBuffer維護者可讀和可寫的指針，也叫游標(biāo)，它指向生產(chǎn)者或消費者需要寫或讀的位置，而對于指針的更新是由CAS來完成的，這個過程中我們不需要加鎖/解鎖的過程。

后記：

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