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