大家好，我是小黑，一個在互聯網茍且偷生的農民工，
在之前的文章中，為了保證在并發情況下多執行緒共享資料的執行緒安全，我們會使用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】,更多干貨內容，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/296979.html
標籤：Java