關(guān)于synchronized

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

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

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

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

自旋鎖的原理

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

關(guān)于偏向鎖

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

關(guān)于Lock

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

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

無鎖時(shí)代

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

后記：

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