AQS原始碼探究---競爭鎖資源
我們進入ReentrantLock原始碼中檢視其內部類
- Sync 對AQS進行擴充套件公共方法並定義抽象方法的抽象類
- FaireSync 實現公平鎖的AQS的實現類
- UnFairSync 實現非公平鎖的ASQ的實現類
我使用例子進行的debug，然後一步一步看原始碼。例子在文章最後面
以下流程皆以非公平鎖為例
執行緒競爭鎖資源
AQS的state解釋：
- 0 表示鎖沒有被佔用
- 1 表示鎖被佔用了
- > 1 表示鎖被重入了 PS： ReentrantLock是可重入鎖
獲得鎖執行流程
- 建立ReentrantLock物件
// ReetrantLock 預設建立一個非公平鎖的AQS
public ReentrantLock() {
sync = new NonfairSync();
}
- 然後我們呼叫lock方法請求鎖
- 成功，即將鎖的owner主人設定為當前執行緒，接下來就是回到執行緒中執行執行緒的任務。
- 失敗，即進入acquire的流程。
static final class NonfairSync extends Sync {
final void lock() {
// 請求鎖資源，如果將鎖的state狀態0改成1，即為成功獲得鎖資源
if (compareAndSetState(0, 1))
// 將鎖的擁有者設定為當前執行緒，裡面就一句話沒啥好看的
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
}
下面是AQS阻塞連結串列是由一個雙向連結串列組成的。
阻塞連結串列的成員物件Node的waitState狀態解釋：
- CANCELLED = 1 表示執行緒已經被取消了
- SIGNAL = -1 表示後繼執行緒需要unpark解除阻塞，下圖即表示。
鎖競爭失敗流程
- 進入acquire方法
public final void acquire(int arg) {
// 首先再次請求鎖
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
- 首先會執行tryAcquire方法
protected final boolean tryAcquire(int acquires) { // 注意：我們進入的是非公平鎖的tryAcquire實現
return nonfairTryAcquire(acquires);
}
再次進入nonfairTryAcquire(acquires)方法
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread(); // 獲得當前執行緒
int c = getState(); // 獲得當前執行緒的狀態
if (c == 0) { // 如果狀態為0即鎖資源被釋放現在處於空閒狀態，會嘗試獲得鎖
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) { // 這裡是可重入程式碼，後面解釋
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false; // 失敗返回false。如果是成功獲得鎖或者是重入都會返回true。需要了解
}
- 回到步驟1程式碼，如果是失敗返回false取反true，就會繼續執行if語句。成功取反後false就直接結束當前語句，就會直接回到執行緒執行執行緒程式碼了。
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) // 這裡是兩個方法，需要一個一個來
selfInterrupt();
}
// acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
- 執行addWaiter方法，概括就是將沒有獲得鎖的加入一個等待連結串列中。
private Node addWaiter(Node mode) { // 剛建立的時候mode為null的
Node node = new Node(Thread.currentThread(), mode); // 首先建立一個node
// Try the fast path of enq; backup to full enq on failure
Node pred = tail; // 將尾部的引用給pred變數
if (pred != null) { // 剛開始建立的時候pred是null的
node.prev = pred;
if (compareAndSetTail(pred, node)) { // 這個程式碼塊就是cas嘗試加入雙向連結串列尾部
pred.next = node;
return node;
}
}
enq(node); // 這裡是建立head和tail進的方法，和if (compareAndSetTail(pred, node))失敗進入
return node; // 方法返回由當前執行緒建立的node
}
enq方法的進入條件
- 進行head和tail的初始化。
- 多執行緒下如果呼叫enq方法失敗，就是當別的執行緒也進入了等待連結串列，此時tail就會改變，上面的cas就會false，沒有返回，就會進行enq方法
private Node enq(final Node node) {
for (;;) {
Node t = tail; // 如果尾部為空就會進行初始化，沒有的話不斷進行cas嘗試插入連結串列尾部。
if (t == null) { // Must initialize 初始化連結串列
if (compareAndSetHead(new Node())) // 我們可以看到head是指向一個沒有引數的node物件的
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node; // 注意t還是引用舊值，而tail已經更新引用為node了。
return t;
}
}
}
}
疑問：
compareAndSetTail(t, node) 方法在我初次遇見的時候很奇怪。為什麼t還算指向了舊的node物件
因為這個compareAndSetTail只是將tail的引用改變成了node，注意這邊改變的是tail的引用。並沒有去改變pred的引用。傳入pred只是保證我們獲得的尾部和現在的尾部是一樣的，才能進行安全的尾部連線。
這也是我基礎不太紮實的原因吧。
- 執行acquireQueued方法，再次嘗試獲得鎖，和進行阻塞
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor(); // 獲得node前驅
if (p == head && tryAcquire(arg)) { // 如果是第一個等待鎖的執行緒，再次請求鎖
setHead(node); // 請求成功就將該執行緒的node直接移出等待連結串列
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) && // 檢查狀態並更新前驅狀態為-1，即表示有後繼節點阻塞了。
parkAndCheckInterrupt()) // 進入park，如果被中斷返回true
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
在parkAndCheckInterrupt方法時進行park阻塞。
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
執行緒釋放鎖
- 呼叫unlock方法
public void unlock() {
sync.release(1);
}
- 呼叫release方法
public final boolean release(int arg) {
if (tryRelease(arg)) { // 進入tryRelease即嘗試釋放
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
進入tryRelease的ReentrantLock實現
protected final boolean tryRelease(int releases) {
int c = getState() - releases; // 獲得當前的狀態
if (Thread.currentThread() != getExclusiveOwnerThread()) // 非獲得鎖執行緒拋異常
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) { // 如果沒有重入直接釋放鎖將owner置為null
free = true;
setExclusiveOwnerThread(null);
}
setState(c); // 由於鎖資源只有一個只有一個執行緒能更新狀態，所以更新AQS狀態不需要cas
return free;
}
- 繼續回到release方法，釋放鎖成功返回true，進入條件語句
public final boolean release(int arg) {
if (tryRelease(arg)) { // 進入tryRelease即嘗試釋放
Node h = head;
if (h != null && h.waitStatus != 0) // 阻塞佇列存在即頭節點不為空且頭節點的狀態不為0，為0表示後面沒節點阻塞了
unparkSuccessor(h);
return true;
}
return false;
}
- 進入unparkSuccessor方法，就不貼原始碼了，簡單介紹一下就是將頭節點置空，將阻塞佇列中第一個等待的node解除阻塞，將他放出來去搶鎖資源。
非公平鎖和公平鎖的區別
看完原始碼，整明白了就是鎖資源釋放後會放第一個等待執行緒去搶鎖。
我就疑惑了，那明明就是公平的啊。
其實只是釋放了執行緒，但是同時有其他的執行緒進行爭搶，就又會變成爭搶的情況，還是可能被其他執行緒搶走鎖資源。
公平鎖
就會判斷如果阻塞連結串列是否為空，為空才能進行獲取鎖資源，又或者是鎖重入
不然就是直接加入阻塞連結串列，從而實現了公平。
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
DEBUG例子
@Slf4j
public class Test1 {
public static void main(String[] args) {
ReentrantLock lock = new ReentrantLock();
// Reentrantlock鎖資源被擁有
new Thread(()->{
lock.lock();
try{
log.debug("執行中");
try {
Thread.sleep(2000000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}finally {
lock.unlock();
}
}).start();
// ReentrantLock阻塞連結串列初始化
new Thread(()->{
lock.lock();
try{
log.debug("執行中");
try {
Thread.sleep(2000000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}finally {
lock.unlock();
}
}).start();
// ReentrantLock 再次向阻塞連結串列新增執行緒
new Thread(()->{
lock.lock();
try{
log.debug("執行中");
try {
Thread.sleep(2000000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}finally {
lock.unlock();
}
}).start();
}
}