ReentrantReadWriteLock讀寫鎖簡單原理案例證實

ReentrantReadWriteLock存在緣由？

---

咱們知道List的實現類ArrayList，LinkedList都是非線程安全的，Vector類經過用synchronized修飾方法保證了List的多線程非安全問題，可是有個缺點：讀寫同步，效率低下。因而就出現了CopyOnWriteArrayList，它經過寫時複製數組實現了讀寫分離，提升了多線程對List讀的效率，適合多讀少些的狀況。同理：咱們知道ReentrantLock，它是一把獨佔的鎖，是用來控制線程同步的，若是咱們用ReentrantLock來實現ArrayList安全，可否達到CopyOnWriteArrayList一樣的效果呢？

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.locks.ReentrantReadWriteLock;

/**
 * @author ：jiaolian
 * @date ：Created in 2021-01-26 15:49
 * @description：ReentrantReadWriteLock多讀少寫的場景
 * @modified By：
 * 公衆號:叫練
 */
public class MultReadTest {


    private static class MyList {
        private final ReentrantReadWriteLock REENTRANT_READ_WRITE_LOCK = new ReentrantReadWriteLock();
        private final ReentrantReadWriteLock.WriteLock WRITE_LOCK = REENTRANT_READ_WRITE_LOCK.writeLock();
        private final ReentrantReadWriteLock.ReadLock READ_LOCK = REENTRANT_READ_WRITE_LOCK.readLock();
        private List<String> list = new ArrayList();

        //讀list
        public void readList() {
            try {
                READ_LOCK.lock();
                Thread.sleep(1000);
                System.out.println(Thread.currentThread().getName()+":"+list.size());
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                READ_LOCK.unlock();
            }
        }

        //寫list
        public void writeList() {
            try {
                WRITE_LOCK.lock();
                Thread.sleep(1000);
                System.out.println(Thread.currentThread().getName()+":新增1個元素");
                list.add("叫練【公衆號】");

            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                WRITE_LOCK.unlock();
            }
        }

    }

    public static void main(String[] args) {
        MyList myList = new MyList();
        //讀寫鎖適合多讀少寫狀況
        //新建10個讀線程，1個寫線程
        new Thread(()->{myList.writeList();},"寫線程").start();
        for (int i=0; i<10; i++) {
            new Thread(()->{myList.readList();},"讀線程"+(i+1)).start();
        }
    }

}

上面案例咱們用ReentrantReadWriteLock實現了CopyOnWriteArrayList，主線程新建了1個寫線程寫list，10個讀線程讀list，程序一共花費2執行完畢，若是用Vector須要花費11秒。在多線程的狀況下，經過讀寫鎖操做List，提升了List的讀效率，在List讀的部分，線程是共享的，在對List寫的過程當中，在對寫的線程是同步的，所以咱們能夠得出一個結論：讀寫鎖是讀讀共享，讀寫同步！

獨佔獲取鎖簡單流程

---

如上圖，咱們簡單的梳理下獨佔獲取鎖流程。

1. 獨佔鎖獲取（上述例子中的WRITE_LOCK寫鎖），首先判斷是否有線程獲取了鎖，是否有線程獲取了鎖的判斷經過讀寫鎖中經過32位int類型state能夠獲取，其中低16位表示讀鎖，高16表示寫鎖。
2. 有讀鎖：直接排隊阻塞。
3. 有寫鎖：還須要判斷寫鎖線程是不是本身，若是是本身就是鎖重入了，若是不是本身說明已經有其餘的線程獲取鎖正在執行，那麼當前線程須要排隊阻塞。
4. 無鎖：直接獲取鎖，其餘搶佔的獨佔鎖線程須要排隊阻塞，當前線程執行完畢後釋放鎖通知下一個排隊線程獲取鎖。

共享獲取鎖簡單流程

---

如上圖，咱們簡單的梳理下共享鎖獲取鎖流程。

1. 獨佔鎖獲取（上述例子中的READ_LOCK讀鎖），首先判斷是否有線程獲取了鎖。
2. 有讀鎖：當前線程發現此時讀鎖狀態被佔用，說明有線程獲取了讀鎖。該線程經過cas自旋【死循環】獲取到讀鎖爲止。
3. 有寫鎖：還須要判斷持有寫鎖的線程是不是本身，若是是本身並且此時是獲取的是讀鎖會獲取鎖成功，咱們稱爲鎖降級，若是不是本身說明此時有其餘線程獲取了寫鎖，那麼當前線程須要排隊阻塞。
4. 無鎖：直接獲取鎖。

寫鎖降級

---

咱們說讀寫互斥，但同一個線程中，先寫後讀也是容許的，咱們稱之爲鎖降級。在面試中共享鎖面試頻率也比較高，方便理解咱們舉個簡單的案例說明下。

import java.util.concurrent.locks.ReentrantReadWriteLock;

/**
 * @author ：jiaolian
 * @date ：Created in 2021-01-28 15:44
 * @description：ReentrantReadWriteLock讀寫鎖降級測試
 * @modified By：
 * 公衆號:叫練
 */
public class WriteLockLowerTest {

    private static final ReentrantReadWriteLock REENTRANT_READ_WRITE_LOCK = new ReentrantReadWriteLock();
    private static final ReentrantReadWriteLock.WriteLock WRITE_LOCK = REENTRANT_READ_WRITE_LOCK.writeLock();
    private static final ReentrantReadWriteLock.ReadLock READ_LOCK = REENTRANT_READ_WRITE_LOCK.readLock();

    public static void main(String[] args) {
        try {
            WRITE_LOCK.lock();
            System.out.println("獲取寫鎖");
            READ_LOCK.lock();
            System.out.println("獲取讀鎖");
        } finally {
            READ_LOCK.unlock();
            System.out.println("釋放寫鎖");
            WRITE_LOCK.unlock();
            System.out.println("釋放讀鎖");
        }
    }
}

如上述代碼：程序能夠運行完畢，說明鎖能夠降級。另外說一句，上面的程序先獲取讀鎖再獲取寫鎖，程序是會阻塞的，爲何呢？歡迎小夥伴在留言區寫下評論！

總結

---

今天咱們用通俗易懂的文字描述了ReentrantReadWriteLock讀寫鎖。喜歡的請點贊加評論哦！點關注，不迷路，我是叫練【公衆號】，邊叫邊練。期待咱們下次再見！