原理剖析（第 009 篇）ReentrantReadWriteLock工作原理分析
一、大致介紹
1、在前面章節(jié)了解了AQS和Semaphore后，想必大家已經(jīng)對獲取獨占鎖、獲取共享鎖有了一定的了解了；
2、而JDK中有一個關(guān)于讀鎖寫鎖分離的工具類，讀鎖是共享鎖，寫鎖是排他鎖，也是基于AQS實現(xiàn)的；
3、那么本章節(jié)就和大家分享分析一下JDK1.8的ReentrantReadWriteLock的工作原理；
二、簡單認識ReentrantReadWriteLock
2.1 何為ReentrantReadWriteLock？
1、ReentrantReadWriteLock從英文字面上可理解為可重入的讀寫鎖；
2、ReentrantReadWriteLock具備讀鎖與寫鎖，讀鎖是共享鎖使用共享模式，寫鎖是排它鎖使用獨占模式；
3、ReentrantReadWriteLock具備公平與非公平策略，"讀-寫"互斥、"寫-寫"互斥；
2.2 ReentrantReadWriteLock的state關(guān)鍵詞
1、ReentrantReadWriteLock的state關(guān)鍵字，有點像ThreadPoolExecutor工作線程數(shù)量值ctl的味道；
2、ReentrantReadWriteLock高16位為讀鎖的計數(shù)值，低16位為寫鎖的計數(shù)值；
2.3 常用重要的成員屬性
1、private final ReentrantReadWriteLock.ReadLock readerLock;
// 讀鎖對象
2、private final ReentrantReadWriteLock.WriteLock writerLock;
// 寫鎖對象
3、final Sync sync;
// 同步器
4、static final int SHARED_SHIFT = 16; // 分界線偏移值，用來向左或向右偏移尾數(shù)，以此來獲取讀寫鎖計數(shù)值
static final int SHARED_UNIT = (1 << SHARED_SHIFT); // 讀鎖需要加1時遞增的增量
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1; // 讀鎖、寫鎖的最大計數(shù)值數(shù)量
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1; // 寫鎖掩碼，用于寫鎖計數(shù)值的低16位有效值
5、private transient ThreadLocalHoldCounter readHolds;
// 保存當(dāng)前線程重入讀鎖次數(shù)的容器，當(dāng)讀鎖重入次數(shù)為0時則會被移除掉
6、private transient HoldCounter cachedHoldCounter;
// 最近一個成功獲取讀鎖的線程的計數(shù)對象
2.4 常用重要的方法
1、public ReentrantReadWriteLock()
// 創(chuàng)建一個讀寫鎖的對象，默認的策略是非公平策略
2、public ReentrantReadWriteLock(boolean fair)
// 創(chuàng)建一個讀寫鎖的對象，且是否公平方式由傳入的fair布爾參數(shù)值決定
3、public ReentrantReadWriteLock.WriteLock writeLock()
// 獲取寫鎖對象
4、public ReentrantReadWriteLock.ReadLock readLock()
// 獲取讀鎖對象
5、public final boolean isFair()
// 查看當(dāng)前的讀寫鎖對象用的策略方式是啥，是公平策略，還是非公平策略
6、protected Thread getOwner()
// 獲取持有獨占鎖的線程對象
7、public int getReadLockCount()
// 獲取持有讀鎖計數(shù)值
8、public boolean isWriteLocked()
// 查看是否有線程持有寫鎖
9、public boolean isWriteLockedByCurrentThread()
// 查看當(dāng)前的線程是不是持有獨占寫鎖的線程
10、public int getWriteHoldCount()
// 獲取當(dāng)前線程在此寫鎖上保持的重入鎖數(shù)量
11、public int getReadHoldCount()
// 獲取當(dāng)前線程在此讀鎖上保持的重入鎖數(shù)量
12、protected Collection<Thread> getQueuedWriterThreads()
// 返回一個 collection，它包含可能正在等待獲取寫入鎖的線程
13、protected Collection<Thread> getQueuedReaderThreads()
// 返回一個 collection，它包含可能正在等待獲取讀取鎖的線程
14、public final boolean hasQueuedThreads()
// 查看是否有阻塞的線程隊列
15、public final boolean hasQueuedThread(Thread thread)
// 查詢給定的線程是否正處于阻塞隊列中
16、abstract boolean readerShouldBlock();
// 抽象方法，由AQS的子類實現(xiàn)，讀鎖是否需要阻塞
17、abstract boolean writerShouldBlock();
// 抽象方法，由AQS的子類實現(xiàn)，寫鎖是否需要阻塞
18、static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
// 獲取讀鎖的計數(shù)值
19、static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
// 獲取寫鎖的計數(shù)值
2.5 設(shè)計與實現(xiàn)偽代碼
1、獲取寫鎖：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
acquire{
如果嘗試獲取獨占鎖失敗的話( 嘗試獲取獨占鎖的各種方式由AQS的子類實現(xiàn) )，
那么就新增獨占鎖結(jié)點通過自旋操作加入到隊列中，并且根據(jù)結(jié)點中的waitStatus來決定是否調(diào)用LockSupport.park進行休息
}
2、釋放寫鎖：
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
release{
如果嘗試釋放獨占鎖成功的話( 嘗試釋放獨占鎖的各種方式由AQS的子類實現(xiàn) )，
那么取出頭結(jié)點并根據(jù)結(jié)點waitStatus來決定是否有義務(wù)喚醒其后繼結(jié)點
}
3、獲取讀鎖：
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
acquireShared{
如果嘗試獲取共享鎖失敗的話( 嘗試獲取共享鎖的各種方式由AQS的子類實現(xiàn) )，
那么新增共享鎖結(jié)點通過自旋操作加入到隊尾中，并且根據(jù)結(jié)點中的waitStatus來決定是否調(diào)用LockSupport.park進行休息
}
4、釋放讀鎖：
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
releaseShared{
如果嘗試釋放共享鎖失敗的話( 嘗試釋放共享鎖的各種方式由AQS的子類實現(xiàn) )，
那么通過自旋操作喚完成阻塞線程的喚起操作
}
三、源碼分析ReentrantReadWriteLock
3.1、Sync同步器
1、AQS --> Sync ---> FairSync // 公平策略
|
|> NonfairSync // 非公平策略
2、ReentrantReadWriteLock內(nèi)的同步器都是通過Sync抽象接口來操作調(diào)用關(guān)系的，細看會發(fā)現(xiàn)基本上都是通過sync.xxx之類的這種調(diào)用方式的；
3.2、ReentrantReadWriteLock構(gòu)造器
1、構(gòu)造器源碼：
// 構(gòu)造方法一：
/**
* Creates a new {@code ReentrantReadWriteLock} with
* default (nonfair) ordering properties.
*/
public ReentrantReadWriteLock() {
this(false);
}
// 構(gòu)造方法二：
/**
* Creates a new {@code ReentrantReadWriteLock} with
* the given fairness policy.
*
* @param fair {@code true} if this lock should use a fair ordering policy
*/
public ReentrantReadWriteLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
readerLock = new ReadLock(this);
writerLock = new WriteLock(this);
}
2、xxxxxxxxxxxxxxxxxxx
3.3、tryAcquire(int)
1、源碼：
// ReentrantReadWriteLock 的靜態(tài)內(nèi)部類 Sync 的 tryAcquire 方法，寫鎖獲取鎖的核心方法
protected final boolean tryAcquire(int acquires) {
/*
* Walkthrough:
* 1. If read count nonzero or write count nonzero
* and owner is a different thread, fail.
* 2. If count would saturate, fail. (This can only
* happen if count is already nonzero.)
* 3. Otherwise, this thread is eligible for lock if
* it is either a reentrant acquire or
* queue policy allows it. If so, update state
* and set owner.
*/
Thread current = Thread.currentThread(); // 獲取當(dāng)前的線程對象
int c = getState(); // 獲取最新的讀寫鎖資源值
int w = exclusiveCount(c); // 然后查看獨占鎖的占有線程數(shù)量
if (c != 0) { // c不為零，說明有線程占有寫鎖
// (Note: if c != 0 and w == 0 then shared count != 0)
// 如果w=0，說明已經(jīng)有線程占有了讀鎖，那么當(dāng)前想獲取寫鎖的話沒必要了，直接返回false到隊列中排隊去
// 如果w!=0，說明已經(jīng)有線程占有了寫鎖，那么再看看當(dāng)前線程是不是那個正在持有寫鎖的線程？
// 如果當(dāng)前線程不是持有寫鎖的那個線程，則返回false到隊列中排隊去；
if (w == 0 || current != getExclusiveOwnerThread())
return false;
// 執(zhí)行到此，說明同一個線程先是持有了寫鎖，然后還想繼續(xù)占有寫鎖，那么就是重入的概念，隨時歡迎重入鎖
if (w + exclusiveCount(acquires) > MAX_COUNT) // 當(dāng)持有寫鎖的數(shù)量超過MAX_COUNT=65535時，則拋出異常，試想一下這個寫鎖如果達到了65535這個數(shù)量級的話，
// 可能是遞歸導(dǎo)致的，可能是其他原因?qū)е碌模凑还茉趺粗偛恢劣诙家绯隽税桑? // 因此是有問題的，所以這里拋出了異常讓調(diào)用方去查查到底是什么原因；
throw new Error("Maximum lock count exceeded");
// Reentrant acquire
setState(c + acquires); // 對于寫鎖的再次重入，來一個收一個，賦值寫鎖狀態(tài)值，然后返回true繼續(xù)執(zhí)行臨界區(qū)的代碼
return true;
}
// 執(zhí)行到此，c=0，也就是說目前還沒有線程占用讀鎖和寫鎖
if (writerShouldBlock() || // 抽象方法需要子類來實現(xiàn)，根據(jù)寫鎖是否需要阻塞的標(biāo)志來判斷，true則需要阻塞，false則不需要阻塞
// writerShouldBlock()在公平策略中，當(dāng)有阻塞隊列時則返回true需要阻塞，無阻塞隊列時返回false不需要阻塞；
// writerShouldBlock()在非公平策略中，永遠都返回false寫鎖不需要阻塞；
!compareAndSetState(c, c + acquires))
// 如果需要阻塞，則直接返回false到隊列中排隊去
// 如果需要阻塞，則通過CAS嘗試占用寫鎖資源，如果嘗試占用寫鎖失敗，說明由于并發(fā)c的值已經(jīng)被改動了，所以還是乖乖到隊列中排隊去
return false;
setExclusiveOwnerThread(current); // 走到這里，說明寫鎖經(jīng)過千辛萬苦終于拿到寫鎖的執(zhí)行權(quán)了，則可以繼續(xù)執(zhí)行臨界區(qū)代碼塊了
return true;
}
2、通過寫鎖writeLock.lock()最終調(diào)用的是Sync的tryAcquire嘗試獲取鎖方式，從而可以得出幾個結(jié)論：
? 已持有讀鎖的線程不能再持有寫鎖；
? 已持有寫鎖的線程可以再持有寫鎖，這和ReentrantLock的重入鎖概念是一致的；
? 已持有讀鎖的線程，其他線程是不能持有寫鎖的；
? 已持有寫鎖的線程，其他線程是不能持有寫鎖的；
3、至于返回false后面是如何進入阻塞隊列的話，這里就不多講了，因為前面已經(jīng)講過了，見( 原理剖析（第 005 篇）AQS工作原理分析 )；
3.4、writerShouldBlock/readerShouldBlock
1、源碼：
/**
* Fair version of Sync：公平策略版本的同步器；
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -2274990926593161451L;
/**
* 公平策略的寫鎖是否需要阻塞，阻塞的判斷依據(jù)就是：當(dāng)有阻塞隊列時則返回true需要阻塞，無阻塞隊列時返回false不需要阻塞；
*/
final boolean writerShouldBlock() {
return hasQueuedPredecessors();
}
/**
* 公平策略的讀鎖是否需要阻塞，阻塞的判斷依據(jù)就是：當(dāng)有阻塞隊列時則返回true需要阻塞，無阻塞隊列時返回false不需要阻塞；
*/
final boolean readerShouldBlock() {
return hasQueuedPredecessors();
}
}
/**
* Nonfair version of Sync：非公平策略版本的同步器；
*/
static final class NonfairSync extends Sync {
private static final long serialVersionUID = -8159625535654395037L;
/**
* 非公平策略的寫鎖是否需要阻塞，阻塞的判斷依據(jù)就是：直接是默認返回false，永遠都返回false寫鎖不需要阻塞；
*/
final boolean writerShouldBlock() {
return false; // writers can always barge
}
/**
* 非公平策略的讀鎖是否需要阻塞，阻塞的判斷依據(jù)就是：阻塞隊列中的第一個結(jié)點是不是獨占式結(jié)點，如果是則返回true表明讀鎖需要阻塞，否則返回false不需要阻塞；
*/
final boolean readerShouldBlock() {
/* As a heuristic to avoid indefinite writer starvation,
* block if the thread that momentarily appears to be head
* of queue, if one exists, is a waiting writer. This is
* only a probabilistic effect since a new reader will not
* block if there is a waiting writer behind other enabled
* readers that have not yet drained from the queue.
*/
return apparentlyFirstQueuedIsExclusive();
}
}
2、FairSync/NonfairSync主要重寫了父類Sync的讀鎖、寫鎖是否需要阻塞，在公平策略與非公平策略中都有各自的實現(xiàn)；
3.5、tryRelease(int)
1、源碼：
// ReentrantReadWriteLock 的靜態(tài)內(nèi)部類 Sync 的 tryRelease 方法，寫鎖釋放鎖的核心方法
protected final boolean tryRelease(int releases) {
if (!isHeldExclusively()) // 如果當(dāng)前線程沒有獲取獨占式鎖的話，也就是說當(dāng)前線程沒有持有寫鎖的話，那么就直接拋異常
throw new IllegalMonitorStateException();
// 之所以拋異常，是因為本來該方法就是持有寫鎖的線程來調(diào)用釋放操作的，但是結(jié)果卻發(fā)現(xiàn)當(dāng)前線程自己沒有吃有寫鎖，
// 那豈不是尷尬，所以期間肯定出現(xiàn)了其他未知的問題，因此直接拋異常，告訴調(diào)用方，肯定有地方用錯了還是啥啥啥的
int nextc = getState() - releases; // 獲取最新的鎖資源值并且做減法操作，減去releases
boolean free = exclusiveCount(nextc) == 0; // 如果得出的nextc=0，那么說明持有寫鎖的線程已經(jīng)完全被釋放了
if (free) // 一般情況下，通過鎖資源值做減法操作，一般都會得到結(jié)果零，則設(shè)置獨占式線程對象exclusiveOwnerThread為空
setExclusiveOwnerThread(null); //
setState(nextc); // 如果能執(zhí)行到此，說明是重入鎖，需要多重釋放才能降低為零，反正如果沒減至零最后都需要更新減后的結(jié)果值
return free; // 返回true說明已經(jīng)沒有線程持有寫鎖了，返回false說明還有線程持有寫鎖
}
2、該方法主要講解了寫鎖如何進行釋放資源，最后不管做減法的結(jié)果如何，都會更新減法之后的結(jié)果賦值到state鎖資源值；
3.6、tryAcquireShared(int)
1、源碼：
// ReentrantReadWriteLock 的靜態(tài)內(nèi)部類 Sync 的 tryAcquireShared 方法，讀鎖獲取鎖的核心方法
protected final int tryAcquireShared(int unused) {
/*
* Walkthrough:
* 1. If write lock held by another thread, fail.
* 2. Otherwise, this thread is eligible for
* lock wrt state, so ask if it should block
* because of queue policy. If not, try
* to grant by CASing state and updating count.
* Note that step does not check for reentrant
* acquires, which is postponed to full version
* to avoid having to check hold count in
* the more typical non-reentrant case.
* 3. If step 2 fails either because thread
* apparently not eligible or CAS fails or count
* saturated, chain to version with full retry loop.
*/
Thread current = Thread.currentThread(); // 獲取當(dāng)前線程對象
int c = getState(); // 獲取內(nèi)存中最新的鎖資源值
if (exclusiveCount(c) != 0 && // 如果有線程持有寫鎖
getExclusiveOwnerThread() != current) // 并且持有寫鎖的線程不是當(dāng)前線程
return -1; // 那么則返回-1表明獲取讀鎖失敗，應(yīng)該乖乖進入CLH阻塞隊列
int r = sharedCount(c); // 獲取讀鎖共享計數(shù)
// readerShouldBlock()在公平策略中，當(dāng)有阻塞隊列時則返回true需要阻塞，無阻塞隊列時返回false不需要阻塞；
// readerShouldBlock()在非公平策略中，阻塞隊列中的第一個結(jié)點是不是獨占式結(jié)點，如果是則返回true表明讀鎖需要阻塞，否則返回false不需要阻塞；
if (!readerShouldBlock() && // 如果讀鎖不需要阻塞處理
r < MAX_COUNT && // 如果讀鎖計數(shù)值沒有超過最大限制值
compareAndSetState(c, c + SHARED_UNIT)) { // 并且通過CAS嘗試獲取讀鎖資源
// 能執(zhí)行到if里面來，說明當(dāng)前線程已經(jīng)成功的突破了重重包圍，準(zhǔn)備看看如何接下來的處理；
if (r == 0) { // 如果成功獲取到讀鎖資源前，發(fā)現(xiàn)之前還沒有任何線程持有讀鎖
firstReader = current; // 則給firstReader對象賦值為第一個獲取讀鎖的線程對象
firstReaderHoldCount = 1; // 并且firstReaderHoldCount第一個線程持有讀鎖次數(shù)初始化次數(shù)為1
} else if (firstReader == current) { // 能執(zhí)行這個判斷，說明讀鎖計數(shù)值肯定不為零，當(dāng)首次獲取讀鎖的線程正好是當(dāng)前線程的話
firstReaderHoldCount++; // 那么firstReaderHoldCount又加1，這里又可以認為重入鎖的概念，但是這里重入的是讀鎖
} else { // 如果執(zhí)行到這里，說明當(dāng)前持有讀鎖的線程不是當(dāng)前線程
HoldCounter rh = cachedHoldCounter; // 獲取最近的一個成功獲取讀鎖的線程的計數(shù)對象
if (rh == null || rh.tid != getThreadId(current)) // 如果rh為空或者rh的線程id不是當(dāng)前線程的話，
cachedHoldCounter = rh = readHolds.get(); // 那么則將readHolds的計數(shù)對象取出來賦值給cachedHoldCounter
// 意思就是說，readHolds里面有最近一次獲取讀鎖的線程的一些簡單的計數(shù)信息
else if (rh.count == 0) // 當(dāng)最近一個的那個計數(shù)對象count=0，則說明HoldCounter還剛剛被創(chuàng)立出來
readHolds.set(rh); // 那么將rh這個對象直接賦值到readHolds中去
rh.count++; // 并且次數(shù)累加一次
}
return 1; // 返回1說明當(dāng)前已經(jīng)成功的獲取到了讀鎖，并且也成功的修改了state這么一個和鎖資源密切相關(guān)的字段
}
// 執(zhí)行到此，有3種情況：
// 1、當(dāng)讀鎖需要阻塞處理的話，則會執(zhí)行到此；
// 2、當(dāng)讀鎖不需要阻塞處理，但是讀鎖的計數(shù)值超過了最大限制值MAX_COUNT=65535，那么也會執(zhí)行到此；
// 3、當(dāng)讀鎖不需要阻塞處理，讀鎖計數(shù)值也沒有超過最大限制值，但是通過CAS嘗試占有讀鎖資源時失敗了，也會執(zhí)行到此
// 總之一句話，沒有順利獲取到讀鎖資源的線程，都會執(zhí)行到這里來；
return fullTryAcquireShared(current); // 獲取讀鎖失敗，則回爐重造通過自旋方式重試
}
2、通過readLock.lock()最終調(diào)用的是Sync的tryAcquireShared嘗試獲取鎖方式，從而可以得出幾個結(jié)論：
? 已持有寫鎖的線程，其他線程是不能持有讀鎖的；
? 已持有寫鎖的線程可以再持有讀鎖，這里我們稱之為鎖降級；
? 已持有讀鎖的線程可以再持有讀鎖，這和ReentrantLock的重入鎖概念是一致的；
? 已持有讀鎖的線程，其他線程也可以持有讀鎖的；
3、至于回爐重造的重試機制和tryAcquireShared操作方式以及代碼非常類似，這里就不再詳講了；
3.7、tryReleaseShared(int)
1、源碼：
// ReentrantReadWriteLock 的靜態(tài)內(nèi)部類 Sync 的 tryReleaseShared 方法，讀鎖釋放鎖的核心方法
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread(); // 獲取當(dāng)前線程對象
if (firstReader == current) { // 如果首次獲取讀鎖的線程為當(dāng)前線程的話
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1) // 如果此刻firstReaderHoldCount次數(shù)正好為1的話，說明該線程的讀鎖沒有重入
firstReader = null; // 則直接將首次獲取讀鎖的線程置為空即可
else
firstReaderHoldCount--; // 若firstReaderHoldCount不為1，則肯定是讀鎖重入了，則需要自減1操作；
} else {
// 執(zhí)行到此，說明當(dāng)前要釋放讀鎖的線程不是那個首次獲取到讀鎖的線程
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) // 獲取最近的那個線程對象，如果不是當(dāng)前線程的話
rh = readHolds.get(); // 那么則通過readHolds獲取最近的那個計數(shù)對象
int count = rh.count; // 取出count值
if (count <= 1) { // 若小于等于1，那么自減1就沒了，所以減都沒減了，直接移除掉，簡單干脆
readHolds.remove(); // 直接移除
if (count <= 0) //
throw unmatchedUnlockException();
}
--rh.count; // 如果大于1的話，則還有的減，那么就自減1操作
}
for (;;) { // 自旋的死循環(huán)操作方式
int c = getState(); // 獲取最新的鎖資源值
int nextc = c - SHARED_UNIT; // 通過計算高位減1處理
if (compareAndSetState(c, nextc)) // 通過嘗試CAS正好設(shè)置成功的話，那么則返回nextc與0的比較
// Releasing the read lock has no effect on readers,
// but it may allow waiting writers to proceed if
// both read and write locks are now free.
return nextc == 0; // 不管如何，只要CAS成功，則表明讀鎖次數(shù)值已經(jīng)被降低釋放了一次了
// 執(zhí)行到此，說明由于并發(fā)的原因?qū)е翪AS失敗，所以需要繼續(xù)循環(huán)再次操作釋放讀鎖次數(shù)操作
}
}
2、該方法主要講解了讀鎖如何進行釋放資源，如果首次釋放失敗的話，則會通過自旋的方式繼續(xù)嘗試釋放資源，直到成功為止；
四、總結(jié)
1、這里有許多其它更底層的沒有分析，因為都是AQS內(nèi)部的基類方法了，而這些基類方法都在之前介紹過了，如果大家不記得的就去翻前面的篇章( 原理剖析（第 005 篇）AQS工作原理分析 )；
2、經(jīng)過上面的一系列分析之后，在這里我再來總結(jié)一下ReentrantReadWriteLock的流程的一些特性；
// ReentrantReadWriteLock.WriteLock.lock()特性：
? 已持有讀鎖的線程不能再持有寫鎖；
? 已持有寫鎖的線程可以再持有寫鎖，這和ReentrantLock的重入鎖概念是一致的；
? 已持有讀鎖的線程，其他線程是不能持有寫鎖的；
? 已持有寫鎖的線程，其他線程是不能持有寫鎖的；
// ReentrantReadWriteLock.ReadLock.lock()特性：
? 已持有寫鎖的線程，其他線程是不能持有讀鎖的；
? 已持有寫鎖的線程可以再持有讀鎖，這里我們稱之為鎖降級；
? 已持有讀鎖的線程可以再持有讀鎖，這和ReentrantLock的重入鎖概念是一致的；
? 已持有讀鎖的線程，其他線程也可以持有讀鎖的；
3、然而將上面的WriteLock\ReadLock特性進行合并為：
? 已持有寫鎖的線程可以再持有寫鎖，這和ReentrantLock的重入鎖概念是一致的；
? 已持有寫鎖的線程，其他線程是不能持有讀鎖、寫鎖的；
? 已持有寫鎖的線程可以再持有讀鎖，這里我們稱之為鎖降級；
? 已持有讀鎖的線程可以再持有讀鎖，這和ReentrantLock的重入鎖概念是一致的；
? 已持有讀鎖的線程，其他線程也可以持有讀鎖的；
? 已持有讀鎖的線程，其他線程(同時也包括已持有讀鎖的線程)是不能持有寫鎖的；
4、排除可重入的特性，再精煉合并特性為：
? 寫鎖會排斥讀鎖、寫鎖，但是讀鎖會阻塞寫鎖；
? 寫鎖可以降級為讀鎖，但讀鎖不能升級為寫鎖；
五、下載地址
https://gitee.com/ylimhhmily/SpringCloudTutorial.git
SpringCloudTutorial交流QQ群: 235322432
SpringCloudTutorial交流微信群: 微信溝通群二維碼圖片鏈接
歡迎關(guān)注，您的肯定是對我最大的支持!!!
