java多線程-讀寫鎖

来源:http://www.cnblogs.com/houziwty/archive/2016/09/02/5833659.html
-Advertisement-
Play Games

Java5 在 java.util.concurrent 包中已經包含了讀寫鎖。儘管如此，我們還是應該瞭解其實現背後的原理。 讀/寫鎖的 Java 實現 先讓我們對讀寫訪問資源的條件做個概述： 讀取 沒有線程正在做寫操作，且沒有線程在請求寫操作。 寫入 沒有線程正在做讀寫操作。 如果某個線程想要讀取 ...


Java5 在 java.util.concurrent 包中已經包含了讀寫鎖。儘管如此，我們還是應該瞭解其實現背後的原理。

  1. 讀/寫鎖的 Java 實現(Read / Write Lock Java Implementation)
  2. 讀/寫鎖的重入(Read / Write Lock Reentrance)
  3. 讀鎖重入(Read Reentrance)
  4. 寫鎖重入(Write Reentrance)
  5. 讀鎖升級到寫鎖(Read to Write Reentrance)
  6. 寫鎖降級到讀鎖(Write to Read Reentrance)
  7. 可重入的 ReadWriteLock 的完整實現(Fully Reentrant ReadWriteLock)
  8. 在 finally 中調用 unlock() (Calling unlock() from a finally-clause)

讀/寫鎖的 Java 實現

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

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

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

如果某個線程想要讀取資源，只要沒有線程正在對該資源進行寫操作且沒有線程請求對該資源的寫操作即可。我們假設對寫操作的請求比對讀操作的請求更重要，就要提升寫請求的優先順序。此外，如果讀操作發生的比較頻繁，我們又沒有提升寫操作的優先順序，那麼就會產生“饑餓”現象。請求寫操作的線程會一直阻塞，直到所有的讀線程都從 ReadWriteLock 上解鎖了。如果一直保證新線程的讀操作許可權，那麼等待寫操作的線程就會一直阻塞下去，結果就是發生“饑餓”。因此，只有當沒有線程正在鎖住 ReadWriteLock 進行寫操作，且沒有線程請求該鎖準備執行寫操作時，才能保證讀操作繼續。

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

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

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 類中，讀鎖和寫鎖各有一個獲取鎖和釋放鎖的方法。

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

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

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

如果有線程在等待獲取讀鎖，同時又有線程在等待獲取寫鎖。如果這時其中一個等待讀鎖的線程被 notify 方法喚醒，但因為此時仍有請求寫鎖的線程存在（writeRequests>0），所以被喚醒的線程會再次進入阻塞狀態。然而，等待寫鎖的線程一個也沒被喚醒，就像什麼也沒發生過一樣（譯者註：信號丟失現象）。如果用的是 notifyAll 方法，所有的線程都會被喚醒，然後判斷能否獲得其請求的鎖。

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

讀/寫鎖的重入

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

  1. Thread 1 獲得了讀鎖。
  2. Thread 2 請求寫鎖，但因為 Thread 1 持有了讀鎖，所以寫鎖請求被阻塞。
  3. Thread 1 再想請求一次讀鎖，但因為 Thread 2 處於請求寫鎖的狀態，所以想再次獲取讀鎖也會被阻塞。 上面這種情形使用前面的 ReadWriteLock 就會被鎖定——一種類似於死鎖的情形。不會再有線程能夠成功獲取讀鎖或寫鎖了。

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

讀鎖重入

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

要保證某個線程中的讀鎖可重入，要麼滿足獲取讀鎖的條件（沒有寫或寫請求），要麼已經持有讀鎖（不管是否有寫請求）。 要確定一個線程是否已經持有讀鎖，可以用一個 map 來存儲已經持有讀鎖的線程以及對應線程獲取讀鎖的次數，當需要判斷某個線程能否獲得讀鎖時，就利用 map 中存儲的數據進行判斷。下麵是方法 lockRead 和 unlockRead 修改後的的代碼：

public class ReadWriteLock{
    private Map<Thread, Integer> readingThreads =
        new HashMap<Thread, Integer>();

    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,
            (getAccessCount(callingThread) + 1));
    }

    public synchronized void unlockRead(){
        Thread callingThread = Thread.currentThread();
        int accessCount = getAccessCount(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.intValue();
    }

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

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

寫鎖重入

僅當一個線程已經持有寫鎖，才允許寫鎖重入（再次獲得寫鎖）。下麵是方法 lockWrite 和 unlockWrite 修改後的的代碼。

public class ReadWriteLock{
    private Map<Thread, Integer> readingThreads =
        new HashMap<Thread, Integer>();

    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;
    }
}

註意在確定當前線程是否能夠獲取寫鎖的時候，是如何處理的。

讀鎖升級到寫鎖

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

public class ReadWriteLock{
    private Map<Thread, Integer> readingThreads =
        new HashMap<Thread, Integer>();

    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 thread){
        return readers == 1 && readingThreads.get(callingThread) != null;
    }
}

現在 ReadWriteLock 類就可以從讀鎖升級到寫鎖了。

寫鎖降級到讀鎖

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

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 的完整實現

下麵是完整的 ReadWriteLock 實現。為了便於代碼的閱讀與理解，簡單對上面的代碼做了重構。重構後的代碼如下。

public class ReadWriteLock{
    private Map<Thread, Integer> readingThreads =
        new HashMap<Thread, Integer>();

    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.intValue();
    }

    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 this.writeRequests > 0;
    }
}

在 finally 中調用 unlock()

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

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

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


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • CURL庫在C++程式中的運用淺析
    最近由於要做一個爬蟲項目，要對很多網站進行爬取，所以一直都在看這方面的文章。在翻閱了很多資料後，下載了一個curl庫，著實對項目有了很大的幫助。 一、LibCurl基本編程框架libcurl是一個跨平臺的網路協議庫，支持http, https, ftp, gopher, telnet, dict, ...
  • Struts2數據校驗
    一.為什麼要進行數據校驗 對於一個web應用而言，所有的應用數據都是通過瀏覽器收集的，用戶的輸入信息是非常複雜的，對於一些用戶操作不熟練，輸入出錯，等網路傳輸不穩定，這些都有可能導致異常輸入。 異常的輸入，輕則導致系統非正常中斷，重則導致系統崩潰，應用程式必須能正常處理表現層接收的異常數據，通常的做 ...
  • Struts2 與Servlet API解耦,耦合的訪問方式
    一.與Servlet API解耦的訪問方式 1.為了避免與Servlet API耦合在一起，方便Action類做單元測試， Struts2對HttpServletRequest、HttpSession和ServletContext進行了封裝， 構造了三個Map對象來替代這三種對象，在Action中， ...
  • Hibernate 之折騰單向多對一映射及其衍生問題
    由於在數據表之間可以通過外鍵進行關聯，在使用Hibernate操作映射到存在關聯關係的數據表的對象時，需要將對象的關聯關係與數據表的外鍵關聯進行映射。 1.前言 這篇文章標題為單向多對一，其實是為以後的種種映射和HQL操作作一個鋪墊，實現單向多對一或者一對多再或者雙向多對一都很簡單，畢竟現在的工具實 ...
  • Selenium常用命令
    openopen(url)- 在瀏覽器中打開URL,可以接受相對和絕對路徑兩種形式type type(inputLocator, value)- 模擬人手的輸入過程，往指定的input中輸入值- 也適合給覆選和單選框賦值 clickclick(elementLocator)- 點擊連接,按鈕，覆選和 ...
  • Scala--高階函數
    一、作為值的函數 結果： 二、匿名函數 三、帶函數參數的函數 結果： 四、參數(類型)推斷 匿名函數簡寫： 五、一些有用的高階函數 map這個方法將一個函數應用到某個集合的所有元素並返回結果 foreach將函數應用到每個元素，並不返回結果 結果： filter輸出所有匹配某個特定條件的元素 結果： ...
  • Python 3.5 for windows 10 通過pip安裝mysqlclient模塊 error:C1083
    $pip install mysqlclient 運行結果如下： 可能是由於不相容導致的（中間試過各種方法，比如本地安裝mysql等等），最後找來mysqlclient-1.3.7-cp35-cp35m-win_amd64.whl資源，安裝成功！ $pip install mysqlclient-1 ...
  • hibernate初步4
    JPA 1.JPA概述 JPA(Java Persistence API)是Sun官方提出的Java持久化規範。它為Java開發人員提供了一種對象/關係映射工具來管理Java應用中的關係數據。，而Hibernate是它的一種實現。除了Hibernate，還有EclipseLink(曾經的toplin ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類