Java5 在 java.util.concurrent 包中已經(jīng)包含了讀寫鎖。盡管如此,我們還是應(yīng)該了解其實(shí)現(xiàn)背后的原理。
讀/寫鎖的 Java 實(shí)現(xiàn)(Read / Write Lock Java Implementation)
讀/寫鎖的重入(Read / Write Lock Reentrance)
讀鎖重入(Read Reentrance)
寫鎖重入(Write Reentrance)
讀鎖升級(jí)到寫鎖(Read to Write Reentrance)
寫鎖降級(jí)到讀鎖(Write to Read Reentrance)
可重入的 ReadWriteLock 的完整實(shí)現(xiàn)(Fully Reentrant ReadWriteLock)
在 finally 中調(diào)用 unlock() (Calling unlock() from a finally-clause)
讀/寫鎖的 Java 實(shí)現(xiàn)
先讓我們對(duì)讀寫訪問資源的條件做個(gè)概述:
讀取 沒有線程正在做寫操作,且沒有線程在請(qǐng)求寫操作。
寫入 沒有線程正在做讀寫操作。
如果某個(gè)線程想要讀取資源,只要沒有線程正在對(duì)該資源進(jìn)行寫操作且沒有線程請(qǐng)求對(duì)該資源的寫操作即可。我們假設(shè)對(duì)寫操作的請(qǐng)求比對(duì)讀操作的請(qǐng)求更重要,就要提升寫請(qǐng)求的優(yōu)先級(jí)。此外,如果讀操作發(fā)生的比較頻繁,我們又沒有提升寫操作的優(yōu)先級(jí),那么就會(huì)產(chǎn)生“饑餓”現(xiàn)象。請(qǐng)求寫操作的線程會(huì)一直阻塞,直到所有的讀線程都從 ReadWriteLock 上解鎖了。如果一直保證新線程的讀操作權(quán)限,那么等待寫操作的線程就會(huì)一直阻塞下去,結(jié)果就是發(fā)生“饑餓”。因此,只有當(dāng)沒有線程正在鎖住 ReadWriteLock 進(jìn)行寫操作,且沒有線程請(qǐng)求該鎖準(zhǔn)備執(zhí)行寫操作時(shí),才能保證讀操作繼續(xù)。
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動(dòng)安全 [無(wú)線安全]玩轉(zhuǎn)無(wú)線電——不安全的藍(lán)牙鎖 2017-07-26
- 消息隊(duì)列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標(biāo)分割】 2017-07-26
- 詞向量-LRWE模型-更好地識(shí)別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實(shí)現(xiàn)JSON轉(zhuǎn)Model - HandyJSON使用講解 2017-07-26
- 阿里移動(dòng)安全 Android端惡意鎖屏勒索應(yīng)用分析 2017-07-26
- 集合結(jié)合數(shù)據(jù)結(jié)構(gòu)來(lái)看看(二) 2017-07-26