本文主要介紹JAVA——以ReentrantLock為例學習重入鎖以及公平性問題。
關注微信公衆号:CodingTechWork,一起學習交流進步。
引言
重入鎖,顧名思義在于這個
重
字。開發過程中,我們在用到鎖時,可能會用于遞歸的方法上加鎖,此時,那同一個方法對象去重複加鎖,是怎麼加的呢?本文一起學習一下重入鎖這個概念。
重入鎖介紹
重入鎖概念
重入鎖ReentrantLock,是指支援重進入的鎖,表示鎖可以支援一個線程對資源的重複加鎖,也就是說任意線程在擷取到這個鎖之後,如果說再次擷取該鎖時,不會被鎖所阻塞(遞歸無阻塞)。另外,重入鎖還支援鎖時的公平和非公平性(預設)選擇。
重入鎖實作
實作重入機制,必須解決兩個問題:1)線程需要再次擷取鎖;2)鎖需要得到最終的釋放。
-
線程再次擷取鎖:
鎖一定要能夠識别擷取鎖的線程是否為目前占據鎖的線程,如果是,則擷取成功。
-
鎖的最終釋放:
鎖擷取對應就會有鎖釋放,線程重複n次擷取了該鎖後,需要在第n次釋放鎖後,其他線程才能夠擷取該鎖。實作機制是計數器:鎖每擷取一次,計數器自增1,該計數表示目前鎖被重複擷取的次數;鎖每釋放一次,計數器自減1,一直減到0,表示目前線程已成功釋放該鎖,其他線程可以來擷取該鎖。
公平鎖和非公平鎖
對于鎖的擷取,會存在公平性的問題。
所謂
公平鎖
,其實就是先對鎖進行擷取的請求肯定優先進行的,鎖擷取的順序符合請求的絕對時間順序,類似于FIFO。反之,即為非公平性鎖。
ReentrantLock源碼分析
/** Synchronizer providing all implementation mechanics */
private final Sync sync;
/**
* Creates an instance of {@code ReentrantLock} with the
* given fairness policy.
*
* @param fair {@code true} if this lock should use a fair ordering policy
*/
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
/**
* Sync object for fair locks
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
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;
}
}
/**
* Sync object for non-fair locks
*/
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*/
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}
/**
* Performs non-fair tryLock. tryAcquire is implemented in
* subclasses, but both need nonfair try for trylock method.
*/
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 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;
}
ReentrantLock的重入性和公平性
ReentrantLock不支援隐式的重入鎖,但是可以在調用
lock()
方法時,已經擷取到鎖的線程,能夠再次調用
lock()
方法擷取鎖且不被阻塞。
從
ReentrantLock
源碼中,我們可以看到上述的一個構造方法,
ReentrantLock
的公平與否,正是通過構造方法來抉擇的,内部類
Sync
繼承了
AQS
,分為公平鎖
FairSync
和非公平鎖
NonfairSync
。如果在絕對的時間上,對鎖先發出擷取請求的線程一定是先被滿足的,這個鎖即為公平的,其實也就是等待時間最長的線程最優先擷取該鎖,是以公平鎖的擷取是順序的。
公平的鎖機制通常沒有非公平的效率高,但是公平鎖可以減少“饑餓”發生的機率,等待越久的請求越是可以得到最先滿足,不會導緻一個線程苦苦等了長時間後得不到滿足。
ReentrantLock非公平性鎖和公平性鎖
...
...
/**
* The synchronization state.
*/
private volatile int state;
/**
* Returns the current value of synchronization state.
* This operation has memory semantics of a {@code volatile} read.
* @return current state value
*/
protected final int getState() {
return state;
}
/**
* The current owner of exclusive mode synchronization.
*/
private transient Thread exclusiveOwnerThread;
/**
* Sets the thread that currently owns exclusive access.
* A {@code null} argument indicates that no thread owns access.
* This method does not otherwise impose any synchronization or
* {@code volatile} field accesses.
* @param thread the owner thread
*/
protected final void setExclusiveOwnerThread(Thread thread) {
exclusiveOwnerThread = thread;
}
...
...
非公平nonfairTryAcquire()源碼
...
...
/**
* Performs non-fair tryLock. tryAcquire is implemented in
* subclasses, but both need nonfair try for trylock method.
*/
final boolean nonfairTryAcquire(int acquires) {
//擷取目前線程
final Thread current = Thread.currentThread();
//擷取同步計數器辨別
int c = getState();
//第一次擷取鎖
if (c == 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");
//設定鎖的計數值,并傳回true
setState(nextc);
return true;
}
//其他線程,傳回false
return false;
}
...
...
非公平鎖是ReentrantLock預設的鎖方式,如何擷取同步狀态?如上述的源碼中顯示該方法增加了再次擷取同步狀态的處理邏輯是通過判斷目前線程是否為擷取鎖的線程,進而決定擷取鎖的操作是true還是false,如果說是擷取鎖的線程發出的請求,則同步狀态值會自增1并傳回true,表示擷取鎖成功;若不是擷取鎖的線程發出的請求 ,則傳回false。隻要
CAS
設定同步狀态值成功,就表示目前線程擷取了鎖。
公平tryAcquire()源碼
...
...
public final boolean hasQueuedPredecessors() {
// The correctness of this depends on head being initialized
// before tail and on head.next being accurate if the current
// thread is first in queue.
Node t = tail; // Read fields in reverse initialization order
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
...
...
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
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;
}
...
...
公平鎖同步計數與非公平鎖的差別在于:公平鎖的方法多了一個
hasQueuedPredecessors()
方法判斷,判斷同步隊列中目前節點是否有前驅節點,如果有,則表示有線程比目前線程更早地發出了擷取鎖的請求,是以需要等待更早的線程擷取并釋放鎖後才能去擷取該鎖。
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;
//将該鎖的獨占線程對象置為null,其他線程可以來擷取鎖。
setExclusiveOwnerThread(null);
}
//設定同步狀态值
setState(c);
return free;
}
...
...
同步狀态值在再次擷取鎖時,自增1,對應的,當釋放鎖是會遞減1。上述源碼中,可以看到如果該鎖被擷取了
n
次,那麼前
(n-1)
次的
tryRelease()
方法必定是傳回了false,隻有當第n次完全釋放鎖,同步狀态值
c==0
,此時獨占鎖的線程對象也被設定為了
null
,才會傳回true,表示完全釋放鎖成功。
測試
package com.example.andya.demo.service;
import javafx.concurrent.Task;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
import java.util.List;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
/**
* @author Andya
* @date 2020/12/6
*/
public class FairAndUnfairLockTest {
//公平鎖
private static Lock fairLock = new ReentrantLockDemo(true);
//非公平鎖
private static Lock unfairLock = new ReentrantLockDemo(false);
//公平鎖線程
public void lockFairTask() {
TaskThread taskThread = new TaskThread(fairLock, "FAIR");
taskThread.start();
}
//非公平鎖線程
public void lockUnfairTask() {
TaskThread taskThread = new TaskThread(unfairLock, "UNFAIR");
taskThread.start();
}
//線程啟動後列印線程資訊
private static class TaskThread extends Thread{
private Lock lock;
private String type;
public TaskThread(Lock lock, String type) {
this.lock = lock;
this.type = type;
}
@Override
public void run() {
for (int i = 0; i < 2; i++) {
lock.lock();
try {
System.out.println(type + " lock by [" + getId() + "], waiting by "
+ ((ReentrantLockDemo)lock).getQueuedThreads());
} finally {
lock.unlock();
}
}
}
//重寫toString方法,使得線程列印出線程id來辨別線程
@Override
public String toString() {
return getId() + "";
}
}
private static class ReentrantLockDemo extends ReentrantLock {
public ReentrantLockDemo(boolean fair) {
super(fair);
}
//擷取正在等待擷取鎖的線程清單
@Override
public Collection<Thread> getQueuedThreads() {
List<Thread> threadList = new ArrayList<>(super.getQueuedThreads());
Collections.reverse(threadList);
return threadList;
}
}
public static void main(String[] args) {
FairAndUnfairLockTest fairAndUnfairLockTest = new FairAndUnfairLockTest();
for (int i = 0; i < 5; i++) {
//公平鎖測試
fairAndUnfairLockTest.lockFairTask();
//非公平鎖測試
// fairAndUnfairLockTest.lockUnfairTask();
}
}
}
結果
// 公平鎖的結果
FAIR lock by [9], waiting by []
FAIR lock by [10], waiting by [11, 12, 9]
FAIR lock by [11], waiting by [12, 9, 13, 10]
FAIR lock by [12], waiting by [9, 13, 10, 11]
FAIR lock by [9], waiting by [13, 10, 11, 12]
FAIR lock by [13], waiting by [10, 11, 12]
FAIR lock by [10], waiting by [11, 12, 13]
FAIR lock by [11], waiting by [12, 13]
FAIR lock by [12], waiting by [13]
FAIR lock by [13], waiting by []
// 非公平鎖的結果
UNFAIR lock by [10], waiting by [9, 11]
UNFAIR lock by [10], waiting by [9, 11, 12, 13]
UNFAIR lock by [9], waiting by [11, 12, 13]
UNFAIR lock by [9], waiting by [11, 12, 13]
UNFAIR lock by [11], waiting by [12, 13]
UNFAIR lock by [11], waiting by [12, 13]
UNFAIR lock by [12], waiting by [13]
UNFAIR lock by [12], waiting by [13]
UNFAIR lock by [13], waiting by []
UNFAIR lock by [13], waiting by []
分析
從結果中我們可以看出來,公平鎖每次都是從同步隊列中的第一個節點擷取鎖,而非公平鎖則是會連續兩次擷取鎖。
剛釋放鎖的線程再次擷取同步狀态的機率比較大,會出現連續擷取鎖的情況。
同時,我們可以看到另一個問題就是開銷,對于公平鎖的開銷會比較大一些,因為它每次都是切換到另一個線程,而對于非公平鎖,會出現連續擷取鎖的現象,切換次數少一些,是以
非公平性鎖的開銷會更小
一些。這也反映了
公平鎖
雖然保證了鎖的擷取按照順序進行,保證了公平性,
解決了“饑餓”問題
,但是代價卻是進行了
大量的線程切換
。
燒不死的鳥就是鳳凰