建站
咨詢
售后
建站咨詢
新聞中心
前言
在多線程開發(fā)中，為了控制線程同步，使用的最多的莫過于synchronized 關(guān)鍵字和重入鎖。在JDK8中，又引入了一款新式武器StampedLock。這是一個(gè)什么東西呢?英文單詞Stamp，意思是郵戳。那在這里有用什么含義呢?傻瓜，請(qǐng)看下面的分解。
成都創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括云陽(yáng)網(wǎng)站建設(shè)、云陽(yáng)網(wǎng)站制作、云陽(yáng)網(wǎng)頁(yè)制作以及云陽(yáng)網(wǎng)絡(luò)營(yíng)銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，云陽(yáng)網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到云陽(yáng)省份的部分城市，未來相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
面對(duì)臨界區(qū)資源管理的問題，大體上有2套思路：
第一就是使用悲觀的策略，悲觀者這樣認(rèn)為：在每一次訪問臨界區(qū)的共享變量，總是有人會(huì)和我沖突，因此，每次訪問我必須先鎖住整個(gè)對(duì)象，完成訪問后再解鎖。
而與之相反的樂天派卻認(rèn)為，雖然臨界區(qū)的共享變量會(huì)沖突，但是沖突應(yīng)該是小概率事件，大部分情況下，應(yīng)該不會(huì)發(fā)生，所以，我可以先訪問了再說，如果等我用完了數(shù)據(jù)還沒人沖突，那么我的操作就是成功;如果我使用完成后，發(fā)現(xiàn)有人沖突，那么我要么再重試一次，要么切換為悲觀的策略。
從這里不難看到，重入鎖以及synchronized 是一種典型的悲觀策略。聰明的你一定也猜到了，StampedLock就是提供了一種樂觀鎖的工具，因此，它是對(duì)重入鎖的一個(gè)重要的補(bǔ)充。
StampedLock的基本使用
在StampedLock的文檔中就提供了一個(gè)非常好的例子，讓我們可以很快的理解StampedLock的使用。下面讓我看一下這個(gè)例子，有關(guān)它的說明，都寫在注釋中了。
這里再說明一下validate()方法的含義，函數(shù)簽名長(zhǎng)這樣：
- public boolean validate(long stamp)
它的接受參數(shù)是上次鎖操作返回的郵戳，如果在調(diào)用validate()之前，這個(gè)鎖沒有寫鎖申請(qǐng)過，那就返回true，這也表示鎖保護(hù)的共享數(shù)據(jù)并沒有被修改，因此之前的讀取操作是肯定能保證數(shù)據(jù)完整性和一致性的。
反之，如果鎖在validate()之前有寫鎖申請(qǐng)成功過，那就表示，之前的數(shù)據(jù)讀取和寫操作沖突了，程序需要進(jìn)行重試，或者升級(jí)為悲觀鎖。
和重入鎖的比較
從上面的例子其實(shí)不難看到，就編程復(fù)雜度來說，StampedLock其實(shí)是要比重入鎖復(fù)雜的多，代碼也沒有以前那么簡(jiǎn)潔了。
那么，我們?yōu)槭裁催€要使用它呢?
最本質(zhì)的原因，就是為了提升性能!一般來說，這種樂觀鎖的性能要比普通的重入鎖快幾倍，而且隨著線程數(shù)量的不斷增加，性能的差距會(huì)越來越大。
簡(jiǎn)而言之，在大量并發(fā)的場(chǎng)景中StampedLock的性能是碾壓重入鎖和讀寫鎖的。
但畢竟，世界上沒有十全十美的東西，StampedLock也并非全能，它的缺點(diǎn)如下：
編碼比較麻煩，如果使用樂觀讀，那么沖突的場(chǎng)景要應(yīng)用自己處理
它是不可重入的，如果一不小心在同一個(gè)線程中調(diào)用了兩次，那么你的世界就清凈了。。。。。
它不支持wait/notify機(jī)制
如果以上3點(diǎn)對(duì)你來說都不是問題，那么我相信StampedLock應(yīng)該成為你的選擇。
內(nèi)部數(shù)據(jù)結(jié)構(gòu)
為了幫助大家更好的理解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ì)列可能看起來像這樣的：
除了這個(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，以此類推。
這里為什么要記錄寫鎖釋放的次數(shù)呢?
這是因?yàn)檎麄€(gè)state 的狀態(tài)判斷都是基于CAS操作的。而普通的CAS操作可能會(huì)遇到ABA的問題，如果不記錄次數(shù)，那么當(dāng)寫鎖釋放掉，申請(qǐng)到，再釋放掉時(shí)，我們將無法判斷數(shù)據(jù)是否被寫過。而這里記錄了釋放的次數(shù)，因此出現(xiàn)"釋放->申請(qǐng)->釋放"的時(shí)候，CAS操作就可以檢查到數(shù)據(jù)的變化，從而判斷寫操作已經(jīng)有發(fā)生，作為一個(gè)樂觀鎖來說，就可以準(zhǔn)確判斷沖突已經(jīng)產(chǎn)生，剩下的就是交給應(yīng)用來解決沖突即可。因此，這里記錄釋放鎖的次數(shù)，是為了精確地監(jiān)控線程沖突。
而state剩下的那一個(gè)字節(jié)的其中7位，用來記錄讀鎖的線程數(shù)量，由于只有7位，因此只能記錄可憐的126個(gè),看下面代碼中的RFULL，就是讀線程滿載的數(shù)量。超過了怎么辦呢，多余的部分就記錄在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)如下：
寫鎖的申請(qǐng)和釋放
在了解了StampedLock的內(nèi)部數(shù)據(jù)結(jié)構(gòu)之后，讓我們?cè)賮砜匆幌掠嘘P(guān)寫鎖的申請(qǐng)和釋放吧!首先是寫鎖的申請(qǐng)：
- public long writeLock() {
- long s, next;
- return ((((s = state) & ABITS) == 0L && //有沒有讀寫鎖被占用，如果沒有，就設(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 ，說明隊(duì)列都沒初始化，就初始化一下隊(duì)列
- 如果隊(duì)列中有其他等待結(jié)點(diǎn)，那么只能老老實(shí)實(shí)入隊(duì)等待了
2.阻塞并等待
- 如果頭結(jié)點(diǎn)等于前置結(jié)點(diǎn)(h = whead) == p), 那說明也快輪到我了，不斷進(jìn)行自旋等待爭(zhēng)搶
- 否則喚醒頭結(jié)點(diǎn)中的讀線程
- 如果搶占不到鎖，那么就park()當(dāng)前線程
簡(jiǎn)單地說，acquireWrite()函數(shù)就是用來爭(zhēng)搶鎖的，它的返回值就是代表當(dāng)前鎖狀態(tài)的郵戳，同時(shí)，為了提高鎖的性能，acquireWrite()使用大量的自旋重試，因此，它的代碼看起來有點(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);
- }
讀鎖的申請(qǐng)和釋放
獲取讀鎖的代碼如下：
- public long readLock() {
- long s = state, next;
- //如果隊(duì)列中沒有寫鎖，并且讀線程個(gè)數(shù)沒有超過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ù)雜，大體上分為這么幾步：
總之，就是自旋，自旋再自旋，通過不斷的自旋來盡可能避免線程被真的掛起，只有當(dāng)自旋充分失敗后，才會(huì)真正讓線程去等待。
下面是釋放讀鎖的過程：
StampedLock悲觀讀占滿CPU的問題
StampedLock固然是個(gè)好東西，但是由于它特別復(fù)雜，難免也會(huì)出現(xiàn)一些小問題。下面這個(gè)例子，就演示了StampedLock悲觀鎖瘋狂占用CPU的問題：
- 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)太多的自旋引起的!沒錯(cuò)，你的猜測(cè)是正確的。
具體原因如下：
如果沒有中斷，那么阻塞在readLock()上的線程在經(jīng)過幾次自旋后，會(huì)進(jìn)入park()等待，一旦進(jìn)入park()等待，就不會(huì)占用CPU了。但是park()這個(gè)函數(shù)有一個(gè)特點(diǎn)，就是一旦線程被中斷，park()就會(huì)立即返回，返回還不算，它也不給你拋點(diǎn)異常啥的，那這就尷尬了。本來呢，你是想在鎖準(zhǔn)備好的時(shí)候，unpark()的線程的，但是現(xiàn)在鎖沒好，你直接中斷了，park()也返回了，但是，畢竟鎖沒好，所以就又去自旋了。
轉(zhuǎn)著轉(zhuǎn)著，又轉(zhuǎn)到了park()函數(shù)，但悲催的是，線程的中斷標(biāo)記一直打開著，park()就阻塞不住了，于是乎，下一個(gè)自旋又開始了，沒完沒了的自旋停不下來了，所以CPU就爆滿了。
要解決這個(gè)問題，本質(zhì)上需要在StampedLock內(nèi)部，在park()返回時(shí)，需要判斷中斷標(biāo)記為，并作出正確的處理，比如，退出，拋異常，或者把中斷位給清理一下，都可以解決問題。
但很不幸，至少在JDK8里，還沒有這樣的處理。因此就出現(xiàn)了上面的，中斷readLock()后，CPU爆滿的問題。請(qǐng)大家一定要注意。
寫在最后
今天，我們比較仔細(xì)地介紹了StampedLock的使用和主要實(shí)現(xiàn)思想，StampedLock是一種重入鎖和讀寫鎖的重要補(bǔ)充。
它提供了一種樂觀鎖的策略，是一種與眾不同的鎖實(shí)現(xiàn)。當(dāng)然了，就編程難度而言，StampedLock會(huì)比重入鎖和讀寫鎖稍微繁瑣一點(diǎn)，但帶來的卻是性能的成倍提升。
這里給大家提一些小意見，如果我們的應(yīng)用線程數(shù)量可控，并且不多，競(jìng)爭(zhēng)不太激烈，那么就可以直接使用簡(jiǎn)單的synchronized,重入鎖，讀寫鎖就好了;如果應(yīng)用線程數(shù)量多，競(jìng)爭(zhēng)激烈，并且對(duì)性能敏感，那么還是需要我們勞神費(fèi)力，用一下比較復(fù)雜的StampedLock，來提高一下程序的吞吐量。
使用StampedLock還需要特別注意兩點(diǎn)：第一StampedLock不是可重入的，千萬不要單線程自己和自己搞死鎖了，第二，StampedLock沒有等待/通知機(jī)制，如果一定需要這個(gè)功能的話，也只能繞行啦!
我是敖丙，你知道的越多，不知道的越多，我們下期見。
本文名稱：聊聊StampedLock的使用和主要實(shí)現(xiàn)思想
當(dāng)前路徑：http://m.5511xx.com/article/dhdscsc.html
