您好,登錄后才能下訂單哦!
這篇文章主要介紹StampedLock怎么用,文中介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們一定要看完!
面對(duì)臨界區(qū)資源管理的問(wèn)題,大體上有2套思路:
第一就是使用悲觀的策略,悲觀者這樣認(rèn)為:在每一次訪問(wèn)臨界區(qū)的共享變量,總是有人會(huì)和我沖突,因此,每次訪問(wèn)我必須先鎖住整個(gè)對(duì)象,完成訪問(wèn)后再解鎖。
而與之相反的樂(lè)天派卻認(rèn)為,雖然臨界區(qū)的共享變量會(huì)沖突,但是沖突應(yīng)該是小概率事件,大部分情況下,應(yīng)該不會(huì)發(fā)生,所以,我可以先訪問(wèn)了再說(shuō),如果等我用完了數(shù)據(jù)還沒(méi)人沖突,那么我的操作就是成功;如果我使用完成后,發(fā)現(xiàn)有人沖突,那么我要么再重試一次,要么切換為悲觀的策略。
從這里不難看到,重入鎖以及synchronized 是一種典型的悲觀策略。聰明的你一定也猜到了,StampedLock就是提供了一種樂(lè)觀鎖的工具,因此,它是對(duì)重入鎖的一個(gè)重要的補(bǔ)充。
在StampedLock的文檔中就提供了一個(gè)非常好的例子,讓我們可以很快的理解StampedLock的使用。下面讓我看一下這個(gè)例子,有關(guān)它的說(shuō)明,都寫在注釋中了。
這里再說(shuō)明一下validate()方法的含義,函數(shù)簽名長(zhǎng)這樣:
public boolean validate(long stamp)
它的接受參數(shù)是上次鎖操作返回的郵戳,如果在調(diào)用validate()之前,這個(gè)鎖沒(méi)有寫鎖申請(qǐng)過(guò),那就返回true,這也表示鎖保護(hù)的共享數(shù)據(jù)并沒(méi)有被修改,因此之前的讀取操作是肯定能保證數(shù)據(jù)完整性和一致性的。
反之,如果鎖在validate()之前有寫鎖申請(qǐng)成功過(guò),那就表示,之前的數(shù)據(jù)讀取和寫操作沖突了,程序需要進(jìn)行重試,或者升級(jí)為悲觀鎖。
從上面的例子其實(shí)不難看到,就編程復(fù)雜度來(lái)說(shuō),StampedLock其實(shí)是要比重入鎖復(fù)雜的多,代碼也沒(méi)有以前那么簡(jiǎn)潔了。
最本質(zhì)的原因,就是為了提升性能!一般來(lái)說(shuō),這種樂(lè)觀鎖的性能要比普通的重入鎖快幾倍,而且隨著線程數(shù)量的不斷增加,性能的差距會(huì)越來(lái)越大。
簡(jiǎn)而言之,在大量并發(fā)的場(chǎng)景中StampedLock的性能是碾壓重入鎖和讀寫鎖的。
但畢竟,世界上沒(méi)有十全十美的東西,StampedLock也并非全能,它的缺點(diǎn)如下:
編碼比較麻煩,如果使用樂(lè)觀讀,那么沖突的場(chǎng)景要應(yīng)用自己處理
它是不可重入的,如果一不小心在同一個(gè)線程中調(diào)用了兩次,那么你的世界就清凈了。。。。。
它不支持wait/notify機(jī)制
如果以上3點(diǎn)對(duì)你來(lái)說(shuō)都不是問(wèn)題,那么我相信StampedLock應(yīng)該成為你的首選。
為了幫助大家更好的理解StampedLock,這里再簡(jiǎn)單給大家介紹一下它的內(nèi)部實(shí)現(xiàn)和數(shù)據(jù)結(jié)構(gòu)。
在StampedLock中,有一個(gè)隊(duì)列,里面存放著等待在鎖上的線程。該隊(duì)列是一個(gè)鏈表,鏈表中的元素是一個(gè)叫做WNode的對(duì)象:
當(dāng)隊(duì)列中有若干個(gè)線程等待時(shí),整個(gè)隊(duì)列可能看起來(lái)像這樣的:
除了這個(gè)等待隊(duì)列,StampedLock中另外一個(gè)特別重要的字段就是long state, 這是一個(gè)64位的整數(shù),StampedLock對(duì)它的使用是非常巧妙的。
state 的初始值是:
private static final int LG_READERS = 7; private static final long WBIT = 1L << LG_READERS; private static final long ORIGIN = WBIT << 1;
也就是 ...0001 0000 0000 (前面的0太多了,不寫了,湊足64個(gè)吧~),為什么這里不用0做初始值呢?因?yàn)?有特殊的含義,為了避免沖突,所以選擇了一個(gè)非零的數(shù)字。
如果有寫鎖占用,那么就讓第7位設(shè)置為1 ...0001 1000 0000,也就是加上WBIT。
每次釋放寫鎖,就加1,但不是state直接加,而是去掉最后一個(gè)字節(jié),只使用前面的7個(gè)字節(jié)做統(tǒng)計(jì)。因此,釋放寫鎖后,state就變成了:...0010 0000 0000, 再加一次鎖,又變成:...0010 1000 0000,以此類推。
這是因?yàn)檎麄€(gè)state 的狀態(tài)判斷都是基于CAS操作的。而普通的CAS操作可能會(huì)遇到ABA的問(wèn)題,如果不記錄次數(shù),那么當(dāng)寫鎖釋放掉,申請(qǐng)到,再釋放掉時(shí),我們將無(wú)法判斷數(shù)據(jù)是否被寫過(guò)。而這里記錄了釋放的次數(shù),因此出現(xiàn)"釋放->申請(qǐng)->釋放"的時(shí)候,CAS操作就可以檢查到數(shù)據(jù)的變化,從而判斷寫操作已經(jīng)有發(fā)生,作為一個(gè)樂(lè)觀鎖來(lái)說(shuō),就可以準(zhǔn)確判斷沖突已經(jīng)產(chǎn)生,剩下的就是交給應(yīng)用來(lái)解決沖突即可。因此,這里記錄釋放鎖的次數(shù),是為了精確地監(jiān)控線程沖突。
而state剩下的那一個(gè)字節(jié)的其中7位,用來(lái)記錄讀鎖的線程數(shù)量,由于只有7位,因此只能記錄可憐的126個(gè),看下面代碼中的RFULL,就是讀線程滿載的數(shù)量。超過(guò)了怎么辦呢,多余的部分就記錄在readerOverflow字段中。
private static final long WBIT = 1L << LG_READERS; private static final long RBITS = WBIT - 1L; private static final long RFULL = RBITS - 1L; private transient int readerOverflow;
總結(jié)一下,state變量的結(jié)構(gòu)如下:
在了解了StampedLock的內(nèi)部數(shù)據(jù)結(jié)構(gòu)之后,讓我們?cè)賮?lái)看一下有關(guān)寫鎖的申請(qǐng)和釋放吧!首先是寫鎖的申請(qǐng):
public long writeLock() { long s, next; return ((((s = state) & ABITS) == 0L && //有沒(méi)有讀寫鎖被占用,如果沒(méi)有,就設(shè)置上寫鎖標(biāo)記 U.compareAndSwapLong(this, STATE, s, next = s + WBIT)) ? //如果寫鎖占用成功范圍next,如果失敗就進(jìn)入acquireWrite()進(jìn)行鎖的占用。 next : acquireWrite(false, 0L)); }
如果CAS設(shè)置state失敗,表示寫鎖申請(qǐng)失敗,這時(shí),會(huì)調(diào)用acquireWrite()進(jìn)行申請(qǐng)或者等待。acquireWrite()大體做了下面幾件事情:
1.入隊(duì)
如果頭結(jié)點(diǎn)等于尾結(jié)點(diǎn)wtail == whead, 表示快輪到我了,所以進(jìn)行自旋等待,搶到就結(jié)束了
如果wtail==null ,說(shuō)明隊(duì)列都沒(méi)初始化,就初始化一下隊(duì)列
如果隊(duì)列中有其他等待結(jié)點(diǎn),那么只能老老實(shí)實(shí)入隊(duì)等待了
2.阻塞并等待
如果頭結(jié)點(diǎn)等于前置結(jié)點(diǎn)(h = whead) == p), 那說(shuō)明也快輪到我了,不斷進(jìn)行自旋等待爭(zhēng)搶
否則喚醒頭結(jié)點(diǎn)中的讀線程
如果搶占不到鎖,那么就park()當(dāng)前線程
簡(jiǎn)單地說(shuō),acquireWrite()函數(shù)就是用來(lái)爭(zhēng)搶鎖的,它的返回值就是代表當(dāng)前鎖狀態(tài)的郵戳,同時(shí),為了提高鎖的性能,acquireWrite()使用大量的自旋重試,因此,它的代碼看起來(lái)有點(diǎn)晦澀難懂。
寫鎖的釋放如下所示,unlockWrite()的傳入?yún)?shù)是申請(qǐng)鎖時(shí)得到的郵戳:
public void unlockWrite(long stamp) { WNode h; //檢查鎖的狀態(tài)是否正常 if (state != stamp || (stamp & WBIT) == 0L) throw new IllegalMonitorStateException(); // 設(shè)置state中標(biāo)志位為0,同時(shí)也起到了增加釋放鎖次數(shù)的作用 state = (stamp += WBIT) == 0L ? ORIGIN : stamp; // 頭結(jié)點(diǎn)不為空,嘗試喚醒后續(xù)的線程 if ((h = whead) != null && h.status != 0) //喚醒(unpark)后續(xù)的一個(gè)線程 release(h); }
獲取讀鎖的代碼如下:
public long readLock() { long s = state, next; //如果隊(duì)列中沒(méi)有寫鎖,并且讀線程個(gè)數(shù)沒(méi)有超過(guò)126,直接獲得鎖,并且讀線程數(shù)量加1 return ((whead == wtail && (s & ABITS) < RFULL && U.compareAndSwapLong(this, STATE, s, next = s + RUNIT)) ? //如果爭(zhēng)搶失敗,進(jìn)入acquireRead()爭(zhēng)搶或者等待 next : acquireRead(false, 0L)); }
acquireRead()的實(shí)現(xiàn)相當(dāng)復(fù)雜,大體上分為這么幾步:
總之,就是自旋,自旋再自旋,通過(guò)不斷的自旋來(lái)盡可能避免線程被真的掛起,只有當(dāng)自旋充分失敗后,才會(huì)真正讓線程去等待。
下面是釋放讀鎖的過(guò)程:
StampedLock固然是個(gè)好東西,但是由于它特別復(fù)雜,難免也會(huì)出現(xiàn)一些小問(wèn)題。下面這個(gè)例子,就演示了StampedLock悲觀鎖瘋狂占用CPU的問(wèn)題:
public class StampedLockTest { public static void main(String[] args) throws InterruptedException { final StampedLock lock = new StampedLock(); Thread t1 = new Thread(() -> { // 獲取寫鎖 lock.writeLock(); // 模擬程序阻塞等待其他資源 LockSupport.park(); }); t1.start(); // 保證t1獲取寫鎖 Thread.sleep(100); Thread t2 = new Thread(() -> { // 阻塞在悲觀讀鎖 lock.readLock(); }); t2.start(); // 保證t2阻塞在讀鎖 Thread.sleep(100); // 中斷線程t2,會(huì)導(dǎo)致線程t2所在CPU飆升 t2.interrupt(); t2.join(); } }
上述代碼中,在中斷t2后,t2的CPU占用率就會(huì)沾滿100%。而這時(shí)候,t2正阻塞在readLock()函數(shù)上,換言之,在受到中斷后,StampedLock的讀鎖有可能會(huì)占滿CPU。這是什么原因呢?機(jī)制的小傻瓜一定想到了,這是因?yàn)镾tampedLock內(nèi)太多的自旋引起的!沒(méi)錯(cuò),你的猜測(cè)是正確的。
如果沒(méi)有中斷,那么阻塞在readLock()上的線程在經(jīng)過(guò)幾次自旋后,會(huì)進(jìn)入park()等待,一旦進(jìn)入park()等待,就不會(huì)占用CPU了。但是park()這個(gè)函數(shù)有一個(gè)特點(diǎn),就是一旦線程被中斷,park()就會(huì)立即返回,返回還不算,它也不給你拋點(diǎn)異常啥的,那這就尷尬了。本來(lái)呢,你是想在鎖準(zhǔn)備好的時(shí)候,unpark()的線程的,但是現(xiàn)在鎖沒(méi)好,你直接中斷了,park()也返回了,但是,畢竟鎖沒(méi)好,所以就又去自旋了。
轉(zhuǎn)著轉(zhuǎn)著,又轉(zhuǎn)到了park()函數(shù),但悲催的是,線程的中斷標(biāo)記一直打開(kāi)著,park()就阻塞不住了,于是乎,下一個(gè)自旋又開(kāi)始了,沒(méi)完沒(méi)了的自旋停不下來(lái)了,所以CPU就爆滿了。
要解決這個(gè)問(wèn)題,本質(zhì)上需要在StampedLock內(nèi)部,在park()返回時(shí),需要判斷中斷標(biāo)記為,并作出正確的處理,比如,退出,拋異常,或者把中斷位給清理一下,都可以解決問(wèn)題。
但很不幸,至少在JDK8里,還沒(méi)有這樣的處理。因此就出現(xiàn)了上面的,中斷readLock()后,CPU爆滿的問(wèn)題。請(qǐng)大家一定要注意。
以上是“StampedLock怎么用”這篇文章的所有內(nèi)容,感謝各位的閱讀!希望分享的內(nèi)容對(duì)大家有幫助,更多相關(guān)知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。