ReentrantLock 0
關於ReentrantLock的文章其實寫過的,但當時寫的感覺不是太好,就給刪了,那為啥又要再寫一遍呢
最近閒著沒事想自己寫個鎖,然後整了幾天出來後不是跑丟執行緒就是和沒加鎖一樣,而且五六段就一個cas效能很差,感覺離大師寫的差十萬八千里
於是!我就想重新研究研究看看大師咋寫的,這篇部落格也算個筆記吧,這篇看的是ReentrantLock的公平鎖,準備寫個兩三篇關於ReentrantLock 就這兩天寫!
這篇部落格完全個人理解,如果有不對的地方歡迎您評論或者私信我,我非常樂意接受您的意見或建議
CAS
首先要知道,ReentrantLock是基本都是在java程式碼層面實現的,而最主要的一個東西就是CAS
compare and swap 比較並交換
這個操作可以看成為是一個原子性的,在java中可以使用反射獲取到Unsafe類來進行cas操作
public test() {
try {
Field unsafeField = Unsafe.class.getDeclaredField("theUnsafe");
if (!unsafeField.isAccessible()) {
unsafeField.setAccessible(true);
}
unsafe = (Unsafe) unsafeField.get(null);
} catch (NoSuchFieldException | IllegalAccessException e) {
e.printStackTrace();
}
}
Park
在juc包下LockSupport類中有兩個方法park
和unpark
這兩個就像是wait和notify/notifyAll,但是又不相同,可以暫時理解為就是暫停執行緒和啟動執行緒
詳細的介紹可以看看這個部落格 : https://www.jianshu.com/p/da76b6ab56be
關於如何使用ReentrantLock就不在贅述了直接開始看程式碼,本來是想把類的關係圖放這的,但是我的idea好像有點問題,你們可以自己開啟idea看,ctrl+alt+u
開啟類的關係圖
public static void main(String[] args) {
ReentrantLock lock = new ReentrantLock(true);
lock.lock();
lock.unlock();
}
構造方法
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
lock方法
public void lock() {
sync.lock();
}
點到裡面實際呼叫的是FairSync
類中的lock()
方法
final void lock() {
acquire(1);
}
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
tryAcuqire方法
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
首先是獲取了當前的執行緒,之後有個getState,這個方法返回的是當前這個鎖的狀態
protected final int getState() {
return state;
}
hasQueuedPredecessors
先來看Node,這個Node是一個組成雙向連結串列的實體類,幾個重要的屬性
volatile int waitStatus;
volatile Node prev;
volatile Node next;
volatile Thread thread;
Node nextWaiter;
waitStatus
存放當前結點的狀態
prev
存放上個結點
next
存放下個結點
thread
存放執行緒
nextWaiter
翻譯是下個服務員,我理解是為下個節點服務,後面我們們細說
public final boolean hasQueuedPredecessors() {
Node t = tail;
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
這裡有兩個屬性,tail尾結點,head頭結點,之後下面一個判斷分別是
頭結點不等於尾結點 並且
(頭結點的下一結點不等於null或者
頭結點後面一個結點的執行緒不等於當前執行緒)
if (c == 0) {
if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
在hasQueuedPredecessors()
接著就是一個cas,修改的這個鎖的狀態
如果成功,則呼叫setExclusiveOwnerThread()
protected final void setExclusiveOwnerThread(Thread thread) {
exclusiveOwnerThread = thread;
}
將當前執行緒存放到exclusiveOwnerThread屬性中
那麼在沒有衝突的情況下lock的方法就走完了,現在我們們假設只有一個執行緒,從頭來捋一下加鎖的過程
試跑一下
我們們順著邏輯捋一下,從最開始的lock()方法開始,前面的就不寫了,直接到acquire
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
進入acquire
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}
因為這個getState()
方法獲取的是屬性state
而這個屬性又沒有其他的賦值操作,初始化就是0,進入if(c==0)
之後進入hasQueuedPredecessors()
public final boolean hasQueuedPredecessors() {
Node t = tail;
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
首先第一個判斷就已經是false了,因為tail和head都沒有進行過初始化,都是null,所以等於,直接返回 false,而在hasQueuedPredecessors()
方法前面還有一個!
取反為true,直接進入if程式碼塊
設定完exclusiveOwnerThread
屬性後就return true,走出lock()方法,加鎖方法結束
exclusiveOwnerThread屬性存放的是當前那個執行緒在佔有鎖
這是在沒有執行緒獲取鎖衝突的情況下,如果現在兩個執行緒同時來的話,還是看tryAcquire
方法
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
我們們現在假設執行緒A獲取到鎖,去執行業務程式碼了,執行緒B進入
getState()
獲取的值就不在是0了,因為執行緒A執行完compareAndSetState(0, acquires)
改的就是getState()
方法獲取的state屬性
那麼進入else if (current == getExclusiveOwnerThread())
哎這個不是獲取當前佔有鎖的那個執行緒的方法嗎,是的
那為什麼有這個判斷呢,ReentrantLock的特性 重入鎖,啥叫重入鎖?:同一個執行緒可以多次獲取同一個鎖
例如下面的例子
public class Test{
private static final ReentrantLock LOCK=new ReentrantLock(true);
public void a(){
LOCK.lock();
b();
LOCK.unlock();
}
public void b(){
LOCK.lock();
//xxxxxx
LOCK.unlock();
}
}
如果沒有重入鎖的特性,那麼這個方法是不是就死鎖了呢?,假設當我們一個執行緒去呼叫a方法時..
-
a : 兄弟我需要鎖才能執行你的程式碼啊
-
b : 那你先解鎖啊
-
a : 我要呼叫完你我才能解鎖啊
-
b : 那你不解鎖咋呼叫我啊
........
好了回到程式碼中,就是將鎖持有的狀態+1,設定後返回true,因為我們現在是B執行緒,所以這個if不成立,返回false
回到acquire方法
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
因為tryAcquire為false,取反繼續執行acquireQueued(addWaiter(Node.EXCLUSIVE), arg)
addWaiter
先來看裡面的addWaiter方法
吧,傳了一個引數Node.EXCLUSIVE
static final Node EXCLUSIVE = null;
這個引數是Node類中的一個屬性
private Node addWaiter(Node mode) {
//建立一個Node
Node node = new Node(Thread.currentThread(), mode);
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
enq(node);
return node;
}
Node的有參構造如下
Node(Thread thread, Node mode) { // Used by addWaiter
this.nextWaiter = mode;
this.thread = thread;
}
首先是建立了一個Node結點,之後判斷如果tail結點不為null,因為A執行緒走完tryAcquire直接返回了,tail和head都是null,所以if不成立,進入enq
方法
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
首先還是獲取tail,那麼這時候還是為null,因為我們的假設就兩個執行緒,A執行緒已經去執行業務了,所以進去第一個if
通過cas來設定頭節點為一個new Node()
注意!這裡是新new的Node,設定完後將頭在設定給尾,那麼此時的節點關係如下
em?? 我們們這B節點也沒有新增進連結串列啊,別急,看看上面的for(;;)
在下次迴圈的時候tail還等於null嗎?答案是否定的
之後還是頭節點賦值給t,將B節點的上一個設定為t,cas設定tail,成功後t節點的next設定為B節點,返回t (返回的值其實沒接收)
挺簡單的邏輯說的太費勁了,還是看圖吧,執行完第二遍for後節點關係如下
這個enq方法是百分百能確定這個節點已經新增進去的,因為你不新增進去就出不來這個方法,那麼返回addWaiter
方法,走完這個enq
就還有一句話,return node;
acquireQueued
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
那麼一進來就定義了一個failed
用來處理如果發生錯誤需要將連結串列中錯誤的節點移除,我們先不看
之後的一個interrupted
存放是否被打斷過,繼續發現還是一個for(;;)
,第一步執行了node.predecessor()
final Node predecessor() throws NullPointerException {
Node p = prev;
if (p == null)
throw new NullPointerException();
else
return p;
}
也就是先獲取了下B節點的上一個,也就是那個執行緒為null的空節點(注意:不是null,而是一個空的Node)
判斷上個節點是不是head,如果是,則嘗試獲取鎖,這個tryAcquire()方法就是開始的那個方法,那麼這一步是什麼意思呢
ReentrantLock的做法,如果必須建立連結串列,則head指向的Node節點一直就是一個空節點
這句話可能不太嚴謹,但是在連結串列存在的大部分時間內,head也確實指向的是一個空節點
繼續看程式碼,假設現在A執行緒還是沒有完成業務程式碼,沒有執行unlock(),那麼我們進入下個if,
if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())
interrupted = true;
shouldParkAfterFailedAcquire
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
return true;
if (ws > 0) {
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
程式碼不多,但是不太好理解 開始還是獲取B節點上個節點的狀態,也就是那個空節點,因為我們們一路程式碼跟過來的,沒有看到哪裡對空節點的state屬性進行過修改,所以它還是0
那麼第一個判斷
static final int SIGNAL = -1; //Node類中的屬性
空節點的狀態是否為-1,顯然不是,if(ws>0)
也不會進,直接進入else,cas修改空節點的狀態,改為了-1,然後返回
if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())
interrupted = true;
因為是&&阻斷了後面的方法,所以不進入,那麼本次迴圈結束,最外層是個for(;;)
所以下次迴圈開始
我們還是假設通過tryAcquire()
沒有獲取到鎖,又進入了shouldParkAfterFailedAcquire
那麼這次第一個if我們就會進去,因為上次迴圈已經將B節點前面的一個空節點的狀態改為-1了,return true
回到if那麼就進入parkAndCheckInterrupt方法
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
park,那麼B執行緒就停在這裡了,把目光回到A執行緒,它終於執行完業務程式碼了,執行unlock
unlock
public void unlock() {
sync.release(1);
}
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
看第一個if中的tryRelease
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
第一件事就是將鎖的狀態-1,因為它重入一次就+1,這也是為什麼呼叫lock多少次就需要呼叫unlock多少次,因為要保證鎖的狀態為0
之後判斷加鎖的執行緒和解鎖的執行緒是不是同一個,不是丟擲異常
boolean free = false;
這個來標識這個鎖是不是已經沒有人持有了,因為A執行緒就呼叫了一次lock,所以if(c==0)
成立
將free 改為true後將當前持有鎖的執行緒設定為null,設定鎖的狀態,返回true,回到release
方法
因為返回true,所以進入if,判斷head節點不為空,並且頭節點的狀態不為0
那麼頭節點是空的嗎? -不是 因為B節點在初始化連結串列是新增了一個空的節點(再說一遍不是null!是空的Node節點)
那麼頭節點的狀態是0嗎? -不是 我們在第二次執行shouldParkAfterFailedAcquire()
方法時已經將頭節點的狀態設定為-1了
那麼進入unparkSuccessor()
private void unparkSuccessor(Node node) {
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);
}
獲取,cas將頭節點的狀態賦值為0,獲取頭節點的下一個節點,也就是我們的B節點,那麼if (s == null || s.waitStatus > 0)
為false,走最下面的if(s!=null)
就一句話 unpark(s.thread)
到此,AB執行緒都走完了
篇幅有點長了,這兩天再接著寫,拜拜?