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ì)讀寫訪問(wèn)資源的條件做個(gè)概述：
讀取 沒(méi)有線程正在做寫操作，且沒(méi)有線程在請(qǐng)求寫操作。
寫入 沒(méi)有線程正在做讀寫操作。
如果某個(gè)線程想要讀取資源，只要沒(méi)有線程正在對(duì)該資源進(jìn)行寫操作且沒(méi)有線程請(qǐng)求對(duì)該資源的寫操作即可。我們假設(shè)對(duì)寫操作的請(qǐng)求比對(duì)讀操作的請(qǐng)求更重要，就要提升寫請(qǐng)求的優(yōu)先級(jí)。此外，如果讀操作發(fā)生的比較頻繁，我們又沒(méi)有提升寫操作的優(yōu)先級(jí)，那么就會(huì)產(chǎn)生“饑餓”現(xiàn)象。請(qǐng)求寫操作的線程會(huì)一直阻塞，直到所有的讀線程都從 ReadWriteLock 上解鎖了。如果一直保證新線程的讀操作權(quán)限，那么等待寫操作的線程就會(huì)一直阻塞下去，結(jié)果就是發(fā)生“饑餓”。因此，只有當(dāng)沒(méi)有線程正在鎖住 ReadWriteLock 進(jìn)行寫操作，且沒(méi)有線程請(qǐng)求該鎖準(zhǔn)備執(zhí)行寫操作時(shí)，才能保證讀操作繼續(xù)。
