大家好，我是小黑，一個在互聯網苟且偷生的農民工。
在之前的文章中，為了保證在並發情況下多線程共享數據的線程安全，我們會使用synchronized關鍵字來修飾方法或者代碼塊，以及在生產者消費者模式中同樣使用synchronized來保證生產者和消費者對於緩沖區的原子操作。
synchronized的缺點
那么synchronized這么厲害，到底有沒有什么缺點呢？主要有以下幾個方面：
- 使用synchronized加鎖的代碼塊或者方法，在線程獲取鎖時，會一直試圖獲取直到獲取成功，不能中斷。
- 加鎖的條件只能在一個鎖對象上，不支持其他條件
- 無法知道鎖對象的狀態，是否被鎖
- synchronized鎖只支持非公平鎖，無法做到公平
- 對於讀操作和寫操作都是使用獨占鎖，無法支持共享鎖（在讀操作時共享，寫操作時獨占）
- synchronized鎖在升級之后不支持降級，如在業務流量高峰階段升級為重量級鎖，流量降低時還是重量級，效率較低（有些JVM實現支持降級，但是降級條件極為苛刻，對於Java線程來說可基本認為是不支持降級）
- 線程間通信無法按條件進行線程的喚醒，如生產者消費者場景中生產者完成數據生產后無法做到只喚醒消費者，其他等待的生產者也會被同時喚醒
以上是我能想到的synchronized鎖的一些缺點，如果你有不同的看法，歡迎私信交流。（沒有留言板的痛/(ㄒoㄒ)/~~）
那么synchronized的這些問題該如何解決呢？或者有沒有替代方案？答案是有的，就是使用我們今天要講的Lock鎖。
Lock的優點
Lock鎖是Java.util.concurrent.locks（JUC）包中的一個接口，並且有很多不同的實現類。這些實現類基本可以完全解決上面我們說到的所有問題。
Lock鎖具備以下優點：
- 支持超時獲取，中斷獲取
- 可以按條件加鎖，靈活性更高
- 支持公平和非公平鎖
- 有獨占鎖和共享鎖的實現，如讀寫鎖
- 可以做到等待線程的精准喚醒
接下來具體看看對應的實現。
基礎鋪墊
在開始之前，先和大家對於一些概念做一下回顧和普及。
可重入鎖
可重入鎖是指鎖具備可重入的特性，可重入的意思是一個線程在獲取鎖之后，如果再次獲取鎖時，可以成功獲取，不會因為鎖正在被占有而死鎖。
synchronized鎖就是可重入鎖，在一個synchronized方法中遞歸調用本方法，可以成功獲取到鎖，不會死鎖。
Lock鎖的實現中基本也都支持可重入。
公平鎖和非公平鎖
公平鎖指在有線程獲取鎖失敗阻塞時，一定會讓先開始阻塞的線程先執行，就好比是排隊買票，排在前面的先買；
非公平鎖則不保證這種公平性，就算有其他線程在阻塞等待，新來的線程也可以直接獲取鎖，就好比插隊。
獨占鎖和共享鎖
獨占鎖是指一把鎖同一時間只能被一個線程持有，舉個生活中的例子，我們使用打車軟件打專車，那么一輛車同一時間只能讓一個用戶打到，這輛專車就好比是一把獨占鎖，被一個用戶獨自占有了嘛。
共享鎖則不一樣，一把鎖可以被多個線程持有，這個就想我們打拼車，一輛拼車同一時間可以讓多個用戶打到，這輛拼車就是一把共享鎖。
說完這些以后我們來看一下Lock接口的一些具體實現。
ReentrantLock
ReentrantLock從名稱理解，就是一把可重入鎖，並且它是一把獨占鎖，而且具有公平和非公平實現。
我們通過代碼來看一下如何通過ReentrantLock來做加解鎖操作。
public static void main(String[] args) {
ReentrantLock lock = new ReentrantLock(false);
lock.lock();
try {
// do something...
}finally {
lock.unlock();
}
}
首先創建一個ReentrantLock對象，在創建時構造方法傳入的boolean值控制是公平鎖還是非公平鎖，如果不傳參數則默認是非公平鎖。
調用lock()方法來進行加鎖，可以看到使用try-finally代碼塊，在finally中進行unlock()解鎖操作，這一點一定要注意，因為lock不會自己進行解鎖，必須手動進行釋放，為了保證鎖一定可以被釋放，防止發生死鎖，所以要在finally中進行。這一點和synchronized有區別，使用synchronized不用關注鎖的釋放時機，這也是為了靈活性必須要付出的一點代價。
ReentrantLock除了通過lock()方法加鎖之外，還有以下方式加鎖：
- tryLock()：只有在調用時它不被另一個線程占用才能獲取鎖
- tryLock(long timeout, TimeUnit unit) 如果在給定的等待時間內沒有被另一個線程占用，並且當前線程尚未被中斷，則獲取該鎖
- lockInterruptibly() 獲取鎖定，除非當前線程是interrupted
除了獲取鎖的方法之外，還有一些其他的方法可以獲得一些鎖相關的狀態信息：
- isLocked() 查詢此鎖是否由任何線程持有
- isHeldByCurrentThread() 查詢此鎖是否由當前線程持有
- getOwner() 返回當前擁有此鎖的線程，如果不擁有，則返回null
ReentrantLock本身是獨占鎖，不支持共享，那么如何做到線程的精准喚醒，我們接着說。
Condition
Condition也是JUC包下的locks包中的一個接口，提供了類似於Object的wait()，notify()，notifyAll()這樣的對象監聽器方法，可以與Lock的實現類配合做到線程的等待/喚醒機制，並且能夠做到精准喚醒。接下來我們看下面的例子：
public class ProdConsDemo {
public static void main(String[] args) {
KFC kfc = new KFC();
new Thread(() -> {
for (int i = 0; i < 100; i++) {
kfc.product();
}
}, "店員1").start();
new Thread(() -> {
for (int i = 0; i < 100; i++) {
kfc.product();
}
}, "店員2").start();
new Thread(() -> {
for (int i = 0; i < 100; i++) {
kfc.consume();
}
}, "顧客1").start();
new Thread(() -> {
for (int i = 0; i < 100; i++) {
kfc.consume();
}
}, "顧客2").start();
}
}
class KFC {
int hamburgerNum = 0;
public synchronized void product() {
while (hamburgerNum == 10) {
try {
// 數量到達最大，生產者等待
this.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println("生產一個漢堡" + (++hamburgerNum));
// 喚醒其他線程
this.notifyAll();
}
public synchronized void consume() {
while (hamburgerNum == 0) {
try {
//數量到達最小，消費者等待
this.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println("賣出一個漢堡" + (hamburgerNum--));
// 喚醒其他線程
this.notifyAll();
}
}
看過小黑之前文章的朋友應該還記得這個例子，KFC里的店員生產漢堡，顧客來消費，典型的生產者消費者模式，我們可以看到在上面的代碼中，是使用的鎖對象this的wait()和notifyAll()方法來做線程等待和喚醒。那么這里會有一個問題，就是在notifyAll()時，無法做到只喚醒消費者或者只喚醒生產者。而在線程被喚醒之后就會面臨更多的線程切換，而線程切換是很消耗CPU資源的。
那么我們使用Condition和ReentrantLock來修改一下我們的代碼。
class KFC {
int hamburgerNum = 0;
ReentrantLock lock = new ReentrantLock();
Condition isEmpty = lock.newCondition();
Condition isFull = lock.newCondition();
public void product() {
lock.lock();
try {
while (hamburgerNum == 10) {
// 數量到達最大，生產者等待
isFull.await();
}
System.out.println("生產一個漢堡" + (++hamburgerNum));
// 喚醒消費者線程
isEmpty.signalAll();
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
public void consume() {
lock.lock();
try {
while (hamburgerNum == 0) {
//數量到達最小，消費者等待
isEmpty.await();
}
System.out.println("賣出一個漢堡" + (hamburgerNum--));
// 喚醒生產者線程
isFull.signalAll();
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
}
可以看到，我們使用ReentrantLock來進行線程安全控制，進行加解鎖，然后創建兩個Condition對象，分別代表生產者和消費者的標記，當生產者生產完一個之后，就會准確的喚醒消費者線程，反之同理。
ReadWriteLock
ReadWriteLock是讀寫鎖接口，通過ReadWriteLock可以實現多個線程對於讀操作共享，對於寫操作獨占。
在ReadWriteLock中有兩個Lock變量，通過兩個Lock分別控制讀和寫。
class Data {
private int num = 0;
private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
private final ReentrantReadWriteLock.ReadLock readLock = lock.readLock();
private final ReentrantReadWriteLock.WriteLock writeLock = lock.writeLock();
public void read() {
readLock.lock();
try {
System.out.println(Thread.currentThread().getName() + "讀取=>" + num);
TimeUnit.SECONDS.sleep(5);
System.out.println(Thread.currentThread().getName() + "讀取結束");
} catch (Exception e) {
e.printStackTrace();
} finally {
readLock.unlock();
}
}
public void write() {
writeLock.lock();
try {
System.out.println(Thread.currentThread().getName() + "寫入=>" + num++);
TimeUnit.SECONDS.sleep(1);
System.out.println(Thread.currentThread().getName() + "寫入結束");
} catch (Exception e) {
e.printStackTrace();
} finally {
writeLock.unlock();
}
}
}
對於讀寫鎖，線程對於鎖的競爭情況如下：
- 讀-讀操作共享；
- 讀-寫操作獨占；
- 寫-讀操作獨占；
- 寫-寫操作獨占；
也就是說，當有一個線程持有讀鎖時，其他線程也可以獲取讀到讀鎖，但是不能獲取寫鎖，必須等讀鎖釋放；當有一個線程持有寫鎖時，其他線程都不能獲取到鎖。
StampedLock
StampedLock是JDK1.8新引入的，主要是為了優化ReadWriteLock的讀寫鎖性能，相比於普通的ReadWriteLock主要多了樂觀獲取讀鎖的功能。
那么ReadWriteLock有什么性能問題呢？主要出現在讀-寫操作上，當有一個線程在讀取時，寫線程只能等讀取完之后才能獲取，讀的過程中不允許寫，是一個悲觀讀鎖。
StampedLock允許在讀的過程中寫，但是這樣會導致我們讀線程獲取的數據不一致，所以需要增加一點代碼來判斷在讀的過程中是否有些操作，這是一種樂觀讀的鎖；我們來看一下代碼。
class Data {
private int num = 0;
private final StampedLock lock = new StampedLock();
public void read() {
// long stamp = lock.readLock();
// 獲取樂觀讀，拿到一個版本戳
long stamp = lock.tryOptimisticRead();
try {
System.out.println(Thread.currentThread().getName() + "讀取=>" + num);
TimeUnit.SECONDS.sleep(5);
System.out.println(Thread.currentThread().getName() + "讀取結束");
// 讀取完之后對剛開始拿到的版本戳進行驗證
if (!lock.validate(stamp)) {
// 驗證不通過，說明發生了寫操作，這是需要重新獲取悲觀讀鎖進行處理
System.out.println("validatefalse");
stamp = lock.readLock();
// do something...
}
} catch (Exception e) {
e.printStackTrace();
} finally {
lock.unlockRead(stamp);
}
}
public void write() {
long stamp = lock.writeLock();
try {
System.out.println(Thread.currentThread().getName() + "寫入=>" + num++);
TimeUnit.SECONDS.sleep(1);
System.out.println(Thread.currentThread().getName() + "寫入結束");
} catch (Exception e) {
e.printStackTrace();
} finally {
lock.unlockWrite(stamp);
}
}
}
所以StampedLock就是先樂觀的認為在讀的過程中不會有寫操作，所以是樂觀鎖，而悲觀鎖就是悲觀的認為在讀的過程中會有些操作，所以拒絕寫入。
顯然在並發高的情況下樂觀鎖的並發效率要更高，但是會有一小部分的寫入導致數據不准確，所以需要通過validate(stamp)檢測出來，重新讀取。
總結
簡單總結一下，首先我們講了synchronized的7個缺點：不能超時中斷；只能在一個對象上加鎖；獲取不到鎖的狀態；不支持公平鎖；不支持共享鎖；鎖升級后不能降級；無法做到精准喚醒阻塞線程等。
然后我們通過Lock的具體實現看到，Lock都解決了這些問題，ReentrantLock支持超時中斷獲取鎖，並且可以按條件判斷進行加鎖，有方法可以看到鎖的狀態信息，支持公平和非公平實現等，通過Condition的await()和signal()/signalAll()可以做到精准喚醒等待線程；ReadWriteLock可以支持共享鎖，讀鎖共享，寫鎖獨占；然后StampedLock在性能上對讀寫鎖進行優化，主要是通過樂觀讀鎖和vaidate(stamp)驗證讀取過程中有沒有寫入。
使用Lock鎖很重要的一點就是需要自己手動釋放鎖，所以一定要寫在finally中；
使用Conditon進行喚醒線程時要記清楚是signal()/signalAll()方法，不是notify()/notifyAll()方法，不要用錯了。
Lock鎖的底層實現邏輯都是依賴於AbstractQueuedSynchronizer（AQS）和CAS無鎖機制來實現的，這部分內容比較復雜，我們下期單獨來說一說。
好的，今天的內容就到這里，我們下期見。
關注我的公眾號【小黑說Java】,更多干貨內容。
