提到鎖，大家肯定想到的是sychronized關(guān)鍵字。是用它可以解決一切并發(fā)問題，但是，對(duì)于系統(tǒng)吞吐量要求更高的話，我們這提供幾個(gè)小技巧。幫助大家減小鎖顆粒度，提高并發(fā)能力。

初級(jí)技巧-樂觀鎖

樂觀鎖使用的場(chǎng)景是，讀不會(huì)沖突，寫會(huì)沖突。同時(shí)讀的頻率遠(yuǎn)大于寫。

 悲觀鎖的實(shí)現(xiàn)：

悲觀的認(rèn)為所有代碼執(zhí)行都會(huì)有并發(fā)問題，所以將所有代碼塊都用sychronized鎖住

樂觀鎖的實(shí)現(xiàn)：

樂觀的認(rèn)為在讀的時(shí)候不會(huì)產(chǎn)生沖突為題，在寫時(shí)添加鎖。所以解決的應(yīng)用場(chǎng)景是讀遠(yuǎn)大于寫時(shí)的場(chǎng)景。

中級(jí)技巧-String.intern()

樂觀鎖不能很好的解決大量的寫沖突的問題，但是很多場(chǎng)景下，鎖只是針對(duì)某個(gè)用戶或者某個(gè)訂單。 比如一個(gè)用戶先創(chuàng)建session，才能進(jìn)行后面的操作，但是由于網(wǎng)絡(luò)的問題，創(chuàng)建session的請(qǐng)求和后續(xù)請(qǐng)求幾乎同時(shí)到達(dá)，而并行線程可能會(huì)先處理后面的請(qǐng)求。一般情況需要對(duì)用戶sessionMap加鎖，比如上面的樂觀鎖。在這樣的場(chǎng)景下，可以將鎖限定在用戶本身上，即原來(lái)的

這個(gè)比較類似行鎖和數(shù)據(jù)庫(kù)表鎖的概念。顯然行鎖的并發(fā)能力比表鎖的高很多。

實(shí)用String.intern();是這種方式的具體實(shí)現(xiàn)。類String維護(hù)了一個(gè)字符串池。當(dāng)調(diào)用intern方法時(shí)，如果池已經(jīng)包含一個(gè)等于此String對(duì)象的字符串（該對(duì)象由equals(Object)方法確定），則返回池中的字符串?？梢?，當(dāng)String 相同時(shí)，總返回同一個(gè)對(duì)象，因此就實(shí)現(xiàn)了對(duì)同一用戶加鎖。由于所的顆粒度局限于具體用戶，使得系統(tǒng)獲得最大程度的并發(fā)。

CopyOnWriteMap？

既然說到了“類似于數(shù)據(jù)庫(kù)中的行鎖的概念”，就不得不提一下MVCC，Java中CopyOnWrite類實(shí)現(xiàn)了MVCC。Copy On Write是這樣一種機(jī)制。當(dāng)我們讀取共享數(shù)據(jù)的時(shí)候，直接讀取，不需要同步。當(dāng)我們修改數(shù)據(jù)的時(shí)候，我們就把當(dāng)前數(shù)據(jù)Copy一份副本，然后在這個(gè)副本 上進(jìn)行修改，完成之后，再用修改后的副本，替換掉原來(lái)的數(shù)據(jù)。這種方法就叫做Copy On Write。

但是，，，JDK并沒有提供CopyOnWriteMap，為什么？下面有個(gè)很好的回答，那就是已經(jīng)有了ConcurrentHashMap，為什么還需要CopyOnWriteMap？

高級(jí)技巧 - 類ConcurrentHashMap

String.inter()的缺陷是類 String 維護(hù)一個(gè)字符串池是放在JVM perm區(qū)的，如果用戶數(shù)特別多，導(dǎo)致放入字符串池的String不可控，有可能導(dǎo)致OOM錯(cuò)誤或者過多的Full GC。怎么樣能控制鎖的個(gè)數(shù)，同時(shí)減小粒度鎖呢？直接使用Java ConcurrentHashMap？或者你想加入自己更精細(xì)的控制？那么可以借鑒ConcurrentHashMap的方式，將需要加鎖的對(duì)象分為多個(gè)bucket，每個(gè)bucket加一個(gè)鎖，偽代碼如下：

到此這篇關(guān)于Java 高并發(fā)的三種實(shí)現(xiàn)案例詳解的文章就介紹到這了,更多相關(guān)Java 高并發(fā)的三種實(shí)現(xiàn)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論