讀寫鎖的java實現(xiàn)

233jl 發(fā)布于2019-08-16 10:53 / 716人閱讀

摘要：如何維護(hù)狀態(tài)內(nèi)部維護(hù)的讀寫狀態(tài)是由位碼表示，高位為讀狀態(tài)，表示持有讀鎖的線程數(shù)，低位為寫狀態(tài)，表示寫鎖的重入次數(shù)，狀態(tài)的改變通過實現(xiàn)，保證同步。寫鎖降級到讀鎖有時擁有寫鎖的線程也希望得到讀鎖。

ReentrantReadWriteLock 如何保證同步

Java中的可重入讀寫鎖ReentrantReadWriteLock是基于AQS（AbstractQueuedSynchronizer）實現(xiàn)的，查看源碼可以發(fā)現(xiàn)內(nèi)部有一個Sync對象繼承自AbstractQueuedSynchronizer，它用來管理同步機(jī)制，java并發(fā)包下的類基本都是用它來提供同步機(jī)制的。

再查看AQS的源碼會發(fā)現(xiàn)其內(nèi)部全是native方法及包裝這些方法的一些其他方法。這些native方法都是調(diào)用本地方法，利用了運(yùn)行機(jī)器CPU的CAS特性。CAS（CompareAndSet）是一種非阻塞算法來保證同步，它的效率通常要比加鎖算法高很多，因為它無阻塞，無掛起和恢復(fù)，無死鎖。簡單來說，比較和替換是使用一個期望值和一個變量的當(dāng)前值進(jìn)行比較，如果當(dāng)前變量的值與我們期望的值相等，就使用一個新值替換當(dāng)前變量的值，返回true，否則返回false，線程可以選擇繼續(xù)做其他事情。關(guān)于CAS可以參考其他博文關(guān)于這方面的解釋。

如何維護(hù)狀態(tài)

ReentrantReadWriteLock內(nèi)部維護(hù)的讀寫狀態(tài)是由32位碼表示，高16位為讀狀態(tài)，表示持有讀鎖的線程數(shù)（sharedCount），低16位為寫狀態(tài)，表示寫鎖的重入次數(shù) （exclusiveCount），狀態(tài)的改變通過AQS實現(xiàn)，保證同步。

關(guān)于ReentrantReadWriteLock的最核心部分大概就是上述兩點，這里不再細(xì)致分析具體代碼實現(xiàn)，它注重了效率但實現(xiàn)方式不容易我們理解一個讀寫鎖到底該有什么東西。因此這里重點通過一個wait/notify版本的讀寫鎖如何實現(xiàn)來深入了解讀寫鎖的原理。

讀寫鎖實現(xiàn)原理 一個簡單的讀寫鎖實現(xiàn)

先讓我們對讀寫訪問資源的條件做個概述：

讀取沒有線程正在做寫操作，且沒有線程在請求寫操作。

寫入沒有線程正在做讀寫操作。

如果某個線程想要讀取資源，只要沒有線程正在對該資源進(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í)行寫操作時，才能保證讀操作繼續(xù)。

當(dāng)其它線程沒有對共享資源進(jìn)行讀操作或者寫操作時，某個線程就有可能獲得該共享資源的寫鎖，進(jìn)而對共享資源進(jìn)行寫操作。有多少線程請求了寫鎖以及以何種順序請求寫鎖并不重要，除非你想保證寫鎖請求的公平性。

按照上面的敘述，簡單的實現(xiàn)出一個讀/寫鎖，代碼如下

public class ReadWriteLock {
    private int readers = 0;
    private int writers = 0;
    private int writeRequests = 0;

    public synchronized void lockRead() throws InterruptedException {
        while (writers > 0 || writeRequests > 0) {
            wait();
        }
        readers++;
    }

    public synchronized void unlockRead() {
        readers--;
        notifyAll();
    }

    public synchronized void lockWrite() throws InterruptedException {
        writeRequests++;

        while (readers > 0 || writers > 0) {
            wait();
        }
        writeRequests--;
        writers++;
    }

    public synchronized void unlockWrite() throws InterruptedException {
        writers--;
        notifyAll();
    }
}

ReadWriteLock類中，讀鎖和寫鎖各有一個獲取鎖和釋放鎖的方法。

讀鎖的實現(xiàn)在lockRead()中,只要沒有線程擁有寫鎖（writers==0），且沒有線程在請求寫鎖（writeRequests ==0），所有想獲得讀鎖的線程都能成功獲取。

寫鎖的實現(xiàn)在lockWrite()中,當(dāng)一個線程想獲得寫鎖的時候，首先會把寫鎖請求數(shù)加1（writeRequests++），然后再去判斷是否能夠真能獲得寫鎖，當(dāng)沒有線程持有讀鎖（readers==0 ）,且沒有線程持有寫鎖（writers==0）時就能獲得寫鎖。有多少線程在請求寫鎖并無關(guān)系。

需要注意的是，在兩個釋放鎖的方法（unlockRead，unlockWrite）中，都調(diào)用了notifyAll方法，而不是notify。要解釋這個原因，我們可以想象下面一種情形：

如果有線程在等待獲取讀鎖，同時又有線程在等待獲取寫鎖。如果這時其中一個等待讀鎖的線程被notify方法喚醒，但因為此時仍有請求寫鎖的線程存在（writeRequests>0），所以被喚醒的線程會再次進(jìn)入阻塞狀態(tài)。然而，等待寫鎖的線程一個也沒被喚醒，就像什么也沒發(fā)生過一樣。如果用的是notifyAll方法，所有的線程都會被喚醒，然后判斷能否獲得其請求的鎖。

用notifyAll還有一個好處。如果有多個讀線程在等待讀鎖且沒有線程在等待寫鎖時，調(diào)用unlockWrite()后，所有等待讀鎖的線程都能立馬成功獲取讀鎖 —— 而不是一次只允許一個。

讀寫鎖的重入

上面實現(xiàn)的讀寫鎖(ReadWriteLock) 是不可重入的，當(dāng)一個已經(jīng)持有寫鎖的線程再次請求寫鎖時，就會被阻塞。原因是已經(jīng)有一個寫線程了——就是它自己。此外，考慮下面的例子：

Thread 1 獲得了讀鎖

Thread 2 請求寫鎖，但因為Thread 1 持有了讀鎖，所以寫鎖請求被阻塞。

Thread 1 再想請求一次讀鎖，但因為Thread 2處于請求寫鎖的狀態(tài)，所以想再次獲取讀鎖也會被阻塞。

上面這種情形使用前面的ReadWriteLock就會被鎖定——一種類似于死鎖的情形。不會再有線程能夠成功獲取讀鎖或?qū)戞i了。

為了讓ReadWriteLock可重入，需要對它做一些改進(jìn)。下面會分別處理讀鎖的重入和寫鎖的重入。

讀鎖重入

為了讓ReadWriteLock的讀鎖可重入，我們要先為讀鎖重入建立規(guī)則：

要保證某個線程中的讀鎖可重入，要么滿足獲取讀鎖的條件（沒有寫或?qū)懻埱螅?，要么已?jīng)持有讀鎖（不管是否有寫請求）。

要確定一個線程是否已經(jīng)持有讀鎖，可以用一個map來存儲已經(jīng)持有讀鎖的線程以及對應(yīng)線程獲取讀鎖的次數(shù)，當(dāng)需要判斷某個線程能否獲得讀鎖時，就利用map中存儲的數(shù)據(jù)進(jìn)行判斷。下面是方法lockRead和unlockRead修改后的的代碼：

public class ReadWriteLock {
    private Map readingThreads = new HashMap();

    private int writers = 0;
    private int writeRequests = 0;

    public synchronized void lockRead() throws InterruptedException {
        Thread callingThread = Thread.currentThread();
        while (!canGrantReadAccess(callingThread)) {
            wait();
        }

        readingThreads.put(callingThread, (getReadAccessCount(callingThread) + 1));
    }

    public synchronized void unlockRead() {
        Thread callingThread = Thread.currentThread();
        int accessCount = getReadAccessCount(callingThread);
        if (accessCount == 1) {
            readingThreads.remove(callingThread);
        } else {
            readingThreads.put(callingThread, (accessCount - 1));
        }
        notifyAll();
    }

    private boolean canGrantReadAccess(Thread callingThread) {
        if (writers > 0)
            return false;
        if (isReader(callingThread))
            return true;
        if (writeRequests > 0)
            return false;
        return true;
    }

    private int getReadAccessCount(Thread callingThread) {
        Integer accessCount = readingThreads.get(callingThread);
        if (accessCount == null)
            return 0;
        return accessCount;
    }

    private boolean isReader(Thread callingThread) {
        return readingThreads.get(callingThread) != null;
    }
}

代碼中我們可以看到，只有在沒有線程擁有寫鎖的情況下才允許讀鎖的重入。此外，重入的讀鎖比寫鎖優(yōu)先級高。

寫鎖重入

僅當(dāng)一個線程已經(jīng)持有寫鎖，才允許寫鎖重入（再次獲得寫鎖）。下面是方法lockWrite和unlockWrite修改后的的代碼。

public class ReadWriteLock {
    private Map readingThreads = new HashMap();

    private int writeAccesses = 0;
    private int writeRequests = 0;
    private Thread writingThread = null;

    public synchronized void lockWrite() throws InterruptedException {
        writeRequests++;
        Thread callingThread = Thread.currentThread();
        while (!canGrantWriteAccess(callingThread)) {
            wait();
        }
        writeRequests--;
        writeAccesses++;
        writingThread = callingThread;
    }

    public synchronized void unlockWrite() throws InterruptedException {
        writeAccesses--;
        if (writeAccesses == 0) {
            writingThread = null;
        }
        notifyAll();
    }

    private boolean canGrantWriteAccess(Thread callingThread) {
        if (hasReaders())
            return false;
        if (writingThread == null)
            return true;
        if (!isWriter(callingThread))
            return false;
        return true;
    }

    private boolean hasReaders() {
        return readingThreads.size() > 0;
    }

    private boolean isWriter(Thread callingThread) {
        return writingThread == callingThread;
    }
}

注意在確定當(dāng)前線程是否能夠獲取寫鎖的時候，是如何處理的。

讀鎖升級到寫鎖

有時，我們希望一個擁有讀鎖的線程，也能獲得寫鎖。想要允許這樣的操作，要求這個線程是唯一一個擁有讀鎖的線程。writeLock()需要做點改動來達(dá)到這個目的：

public class ReadWriteLock {
    private Map readingThreads = new HashMap();

    private int writeAccesses = 0;
    private int writeRequests = 0;
    private Thread writingThread = null;

    public synchronized void lockWrite() throws InterruptedException {
        writeRequests++;
        Thread callingThread = Thread.currentThread();
        while (!canGrantWriteAccess(callingThread)) {
            wait();
        }
        writeRequests--;
        writeAccesses++;
        writingThread = callingThread;
    }

    public synchronized void unlockWrite() throws InterruptedException {
        writeAccesses--;
        if (writeAccesses == 0) {
            writingThread = null;
        }
        notifyAll();
    }

    private boolean canGrantWriteAccess(Thread callingThread) {
        if (isOnlyReader(callingThread))
            return true;
        if (hasReaders())
            return false;
        if (writingThread == null)
            return true;
        if (!isWriter(callingThread))
            return false;
        return true;
    }

    private boolean hasReaders() {
        return readingThreads.size() > 0;
    }

    private boolean isWriter(Thread callingThread) {
        return writingThread == callingThread;
    }

    private boolean isOnlyReader(Thread callingThread) {
        return readers == 1 && readingThreads.get(callingThread) != null;
    }
}

現(xiàn)在ReadWriteLock類就可以從讀鎖升級到寫鎖了。

寫鎖降級到讀鎖

有時擁有寫鎖的線程也希望得到讀鎖。如果一個線程擁有了寫鎖，那么自然其它線程是不可能擁有讀鎖或?qū)戞i了。所以對于一個擁有寫鎖的線程，再獲得讀鎖，是不會有什么危險的。我們僅僅需要對上面canGrantReadAccess方法進(jìn)行簡單地修改：

public class ReadWriteLock {
    private boolean canGrantReadAccess(Thread callingThread) {
        if (isWriter(callingThread))
            return true;
        if (writingThread != null)
            return false;
        if (isReader(callingThread))
            return true;
        if (writeRequests > 0)
            return false;
        return true;
    }
}

可重入的ReadWriteLock的完整實現(xiàn)

下面是完整的ReadWriteLock實現(xiàn)。為了便于代碼的閱讀與理解，簡單對上面的代碼做了重構(gòu)。重構(gòu)后的代碼如下。

public class ReadWriteLock {

    private Map readingThreads = new HashMap();

    private int writeAccesses = 0;
    private int writeRequests = 0;
    private Thread writingThread = null;

    public synchronized void lockRead() throws InterruptedException {
        Thread callingThread = Thread.currentThread();
        while (!canGrantReadAccess(callingThread)) {
            wait();
        }

        readingThreads.put(callingThread, (getReadAccessCount(callingThread) + 1));
    }

    private boolean canGrantReadAccess(Thread callingThread) {
        if (isWriter(callingThread))
            return true;
        if (hasWriter())
            return false;
        if (isReader(callingThread))
            return true;
        if (hasWriteRequests())
            return false;
        return true;
    }

    public synchronized void unlockRead() {
        Thread callingThread = Thread.currentThread();
        if (!isReader(callingThread)) {
            throw new IllegalMonitorStateException("Calling Thread does not hold a read lock on this ReadWriteLock");
        }
        int accessCount = getReadAccessCount(callingThread);
        if (accessCount == 1) {
            readingThreads.remove(callingThread);
        } else {
            readingThreads.put(callingThread, (accessCount - 1));
        }
        notifyAll();
    }

    public synchronized void lockWrite() throws InterruptedException {
        writeRequests++;
        Thread callingThread = Thread.currentThread();
        while (!canGrantWriteAccess(callingThread)) {
            wait();
        }
        writeRequests--;
        writeAccesses++;
        writingThread = callingThread;
    }

    public synchronized void unlockWrite() throws InterruptedException {
        if (!isWriter(Thread.currentThread())) {
            throw new IllegalMonitorStateException("Calling Thread does not hold the write lock on this ReadWriteLock");
        }
        writeAccesses--;
        if (writeAccesses == 0) {
            writingThread = null;
        }
        notifyAll();
    }

    private boolean canGrantWriteAccess(Thread callingThread) {
        if (isOnlyReader(callingThread))
            return true;
        if (hasReaders())
            return false;
        if (writingThread == null)
            return true;
        if (!isWriter(callingThread))
            return false;
        return true;
    }

    private int getReadAccessCount(Thread callingThread) {
        Integer accessCount = readingThreads.get(callingThread);
        if (accessCount == null)
            return 0;
        return accessCount;
    }

    private boolean hasReaders() {
        return readingThreads.size() > 0;
    }

    private boolean isReader(Thread callingThread) {
        return readingThreads.get(callingThread) != null;
    }

    private boolean isOnlyReader(Thread callingThread) {
        return readingThreads.size() == 1 && readingThreads.get(callingThread) != null;
    }

    private boolean hasWriter() {
        return writingThread != null;
    }

    private boolean isWriter(Thread callingThread) {
        return writingThread == callingThread;
    }

    private boolean hasWriteRequests() {
        return writeRequests > 0;
    }
}

在finally中調(diào)用unlock()

在利用ReadWriteLock來保護(hù)臨界區(qū)時，如果臨界區(qū)可能拋出異常，在finally塊中調(diào)用readUnlock()和writeUnlock()就顯得很重要了。這樣做是為了保證ReadWriteLock能被成功解鎖，然后其它線程可以請求到該鎖。這里有個例子：

lock.lockWrite();
try{
    //do critical section code, which may throw exception
} finally {
    lock.unlockWrite();
}

上面這樣的代碼結(jié)構(gòu)能夠保證臨界區(qū)中拋出異常時ReadWriteLock也會被釋放。如果unlockWrite方法不是在finally塊中調(diào)用的，當(dāng)臨界區(qū)拋出了異常時，ReadWriteLock 會一直保持在寫鎖定狀態(tài)，就會導(dǎo)致所有調(diào)用lockRead()或lockWrite()的線程一直阻塞。唯一能夠重新解鎖ReadWriteLock的因素可能就是ReadWriteLock是可重入的，當(dāng)拋出異常時，這個線程后續(xù)還可以成功獲取這把鎖，然后執(zhí)行臨界區(qū)以及再次調(diào)用unlockWrite()，這就會再次釋放ReadWriteLock。但是如果該線程后續(xù)不再獲取這把鎖了呢？所以，在finally中調(diào)用unlockWrite對寫出健壯代碼是很重要的。

個人博客：www.hellolvs.com

GPU云服務(wù)器云服務(wù)器 java讀寫鎖的作用讀寫分離怎么實現(xiàn) 如何實現(xiàn)讀寫分離 mysql讀寫分離實現(xiàn)方式

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/70664.html

發(fā)表評論

登陸后可評論

0條評論

233jl

男|高級講師

我要關(guān)注我要私信

TA的文章

Python控制單片機(jī) TPYBoard MicroPython v202鏈接DTH11 溫濕度 m

閱讀 1397·2021-11-24 09:38
Web優(yōu)化躬行記（5）——網(wǎng)站優(yōu)化

閱讀 3325·2021-11-22 12:03
域名續(xù)費貴怎么辦？合理利用域名商家轉(zhuǎn)入優(yōu)惠省錢策略

閱讀 4349·2021-11-11 10:59
前程無憂崗位數(shù)據(jù)爬取+Tableau可視化分析

閱讀 2423·2021-09-28 09:36
高性能MySQL讀書筆記(2)--MySQL基準(zhǔn)測試

閱讀 1103·2021-09-09 09:32
RAKsmart新增彈性云服務(wù)器首推硅谷機(jī)房可選優(yōu)化/精品/CN2線路

閱讀 3553·2021-08-05 10:00
運(yùn)維日迎新，歡迎“U仔”——UCloud吉祥物正式出道

閱讀 2618·2021-07-23 15:30
css記錄收集

閱讀 3050·2019-08-30 13:12

亚洲中字慕日产2020,大陆极品少妇内射AAAAAA,无码av大香线蕉伊人久久,久久精品国产亚洲av麻豆网站

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺、長期優(yōu)惠，快來選購！

讀寫鎖的java實現(xiàn)

相關(guān)文章

Java 中15種鎖的介紹：公平鎖，可重入鎖，獨享鎖，互斥鎖，樂觀鎖，分段鎖，自旋鎖等等

Java中的鎖以及sychronized實現(xiàn)機(jī)制

Java中的鎖

**[Java并發(fā)-10] ReadWriteLock：快速實現(xiàn)一個完備的緩存**

Java多線程進(jìn)階（十）—— J.U.C之locks框架：基于AQS的讀寫鎖(5)

發(fā)表評論

0條評論

233jl

男|高級講師

TA的文章

Python控制單片機(jī) TPYBoard MicroPython v202鏈接DTH11 溫濕度 m

Web優(yōu)化躬行記（5）——網(wǎng)站優(yōu)化

域名續(xù)費貴怎么辦？合理利用域名商家轉(zhuǎn)入優(yōu)惠省錢策略

前程無憂崗位數(shù)據(jù)爬取+Tableau可視化分析

高性能MySQL讀書筆記(2)--MySQL基準(zhǔn)測試

RAKsmart新增彈性云服務(wù)器首推硅谷機(jī)房可選優(yōu)化/精品/CN2線路

運(yùn)維日迎新，歡迎“U仔”——UCloud吉祥物正式出道

css記錄收集

最新活動

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺、長期優(yōu)惠，快來選購！

讀寫鎖的java實現(xiàn)

相關(guān)文章

發(fā)表評論

0條評論

男|高級講師

TA的文章

最新活動

上云采購季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺、長期優(yōu)惠，快來選購！