[[342267]]

作者個人研發的在高并發場景下，提供的簡單、穩定、可擴展的延遲消息隊列框架，具有精準的定時任務和延遲隊列處理功能。自開源半年多以來，已成功為十幾家中小型企業提供了精準定時調度方案，經受住了生產環境的考驗。為使更多童鞋受益，現給出開源框架地址：

https://github.com/sunshinelyz/mykit-delay

寫在前面

在Java中提供了synchronized關鍵字來保證只有一個線程能夠訪問同步代碼塊。既然已經提供了synchronized關鍵字，那為何在Java的SDK包中，還會提供Lock接口呢?這是不是重復造輪子，多此一舉呢?今天，我們就一起來探討下這個問題。

再造輪子?

既然JVM中提供了synchronized關鍵字來保證只有一個線程能夠訪問同步代碼塊，為何還要提供Lock接口呢?這是在重復造輪子嗎?Java的設計者們為何要這樣做呢?讓我們一起帶著疑問往下看。

為何提供Lock接口?

很多小伙伴可能會聽說過，在Java 1.5版本中，synchronized的性能不如Lock，但在Java 1.6版本之后，synchronized做了很多優化，性能提升了不少。那既然synchronized關鍵字的性能已經提升了，那為何還要使用Lock呢?

如果我們向更深層次思考的話，就不難想到了：我們使用synchronized加鎖是無法主動釋放鎖的，這就會涉及到死鎖的問題。

死鎖問題

如果要發生死鎖，則必須存在以下四個必要條件，四者缺一不可。

互斥條件

在一段時間內某資源僅為一個線程所占有。此時若有其他線程請求該資源，則請求線程只能等待。

不可剝奪條件

線程所獲得的資源在未使用完畢之前，不能被其他線程強行奪走，即只能由獲得該資源的線程自己來釋放(只能是主動釋放)。

請求與保持條件

線程已經保持了至少一個資源，但又提出了新的資源請求，而該資源已被其他線程占有，此時請求線程被阻塞，但對自己已獲得的資源保持不放。

循環等待條件

在發生死鎖時必然存在一個進程等待隊列{P1,P2,…,Pn},其中P1等待P2占有的資源，P2等待P3占有的資源，…，pn等待p1占有的資源，形成一個進程等待環路，環路中每一個進程所占有的資源同時被另一個申請，也就是前一個進程占有后一個進程所深情地資源。

synchronized的局限性

如果我們的程序使用synchronized關鍵字發生了死鎖時，synchronized關鍵是是無法破壞“不可剝奪”這個死鎖的條件的。這是因為synchronized申請資源的時候， 如果申請不到， 線程直接進入阻塞狀態了， 而線程進入阻塞狀態， 啥都干不了， 也釋放不了線程已經占有的資源。

然而，在大部分場景下，我們都是希望“不可剝奪”這個條件能夠被破壞。也就是說對于“不可剝奪”這個條件，占用部分資源的線程進一步申請其他資源時， 如果申請不到， 可以主動釋放它占有的資源， 這樣不可剝奪這個條件就破壞掉了。

如果我們自己重新設計鎖來解決synchronized的問題，我們該如何設計呢?

解決問題

了解了synchronized的局限性之后，如果是讓我們自己實現一把同步鎖，我們該如何設計呢?也就是說，我們在設計鎖的時候，要如何解決synchronized的局限性問題呢?這里，我覺得可以從三個方面來思考這個問題。

(1)能夠響應中斷。synchronized的問題是， 持有鎖A后， 如果嘗試獲取鎖B失敗， 那么線程就進入阻塞狀態， 一旦發生死鎖， 就沒有任何機會來喚醒阻塞的線程。但如果阻塞狀態的線程能夠響應中斷信號， 也就是說當我們給阻塞的線程發送中斷信號的時候， 能夠喚醒它， 那它就有機會釋放曾經持有的鎖A。這樣就破壞了不可剝奪條件了。

(2)支持超時。如果線程在一段時間之內沒有獲取到鎖， 不是進入阻塞狀態， 而是返回一個錯誤， 那這個線程也有機會釋放曾經持有的鎖。這樣也能破壞不可剝奪條件。

(3)非阻塞地獲取鎖。如果嘗試獲取鎖失敗， 并不進入阻塞狀態， 而是直接返回， 那這個線程也有機會釋放曾經持有的鎖。這樣也能破壞不可剝奪條件。

體現在Lock接口上，就是Lock接口提供的三個方法，如下所示。

// 支持中斷的API 
void lockInterruptibly() throws InterruptedException; 
// 支持超時的API 
boolean tryLock(long time, TimeUnit unit) throws InterruptedException; 
// 支持非阻塞獲取鎖的API 
boolean tryLock(); 

lockInterruptibly()

支持中斷。

tryLock()方k

tryLock()方法是有返回值的，它表示用來嘗試獲取鎖，如果獲取成功，則返回true，如果獲取失敗(即鎖已被其他線程獲取)，則返回false，也就說這個方法無論如何都會立即返回。在拿不到鎖時不會一直在那等待。

tryLock(long time, TimeUnit unit)方法

tryLock(long time, TimeUnit unit)方法和tryLock()方法是類似的，只不過區別在于這個方法在拿不到鎖時會等待一定的時間，在時間期限之內如果還拿不到鎖，就返回false。如果一開始拿到鎖或者在等待期間內拿到了鎖，則返回true。

也就是說，對于死鎖問題，Lock能夠破壞不可剝奪的條件，例如，我們下面的程序代碼就破壞了死鎖的不可剝奪的條件。

public class TansferAccount{ 
    private Lock thisLock = new ReentrantLock(); 
    private Lock targetLock = new ReentrantLock(); 
    //賬戶的余額 
    private Integer balance; 
    //轉賬操作 
    public void transfer(TansferAccount target, Integer transferMoney){ 
        boolean isThisLock = thisLock.tryLock(); 
        if(isThisLock){ 
            try{ 
                boolean isTargetLock = targetLock.tryLock(); 
                if(isTargetLock){ 
                    try{ 
                         if(this.balance >= transferMoney){ 
                            this.balance -= transferMoney; 
                            target.balance += transferMoney; 
                        }    
                    }finally{ 
                        targetLock.unlock 
                    } 
                } 
            }finally{ 
                thisLock.unlock(); 
            } 
        } 
    } 
} 

例外，Lock下面有一個ReentrantLock，而ReentrantLock支持公平鎖和非公平鎖。

在使用ReentrantLock的時候， ReentrantLock中有兩個構造函數， 一個是無參構造函數， 一個是傳入fair參數的構造函數。fair參數代表的是鎖的公平策略， 如果傳入true就表示需要構造一個公平鎖， 反之則表示要構造一個非公平鎖。如下代碼片段所示。

//無參構造函數： 默認非公平鎖 
public ReentrantLock() { 
 sync = new NonfairSync(); 
}  
//根據公平策略參數創建鎖 
public ReentrantLock(boolean fair){ 
 sync = fair ? new FairSync() : new NonfairSync(); 
} 

鎖的實現在本質上都對應著一個入口等待隊列， 如果一個線程沒有獲得鎖， 就會進入等待隊列， 當有線程釋放鎖的時候， 就需要從等待隊列中喚醒一個等待的線程。如果是公平鎖， 喚醒的策略就是誰等待的時間長， 就喚醒誰， 很公平;如果是非公平鎖， 則不提供這個公平保證， 有可能等待時間短的線程反而先被喚醒。 而Lock是支持公平鎖的，synchronized不支持公平鎖。

最后，值得注意的是，在使用Lock加鎖時，一定要在finally{}代碼塊中釋放鎖，例如，下面的代碼片段所示。

try{ 
    lock.lock(); 
}finally{ 
    lock.unlock(); 
} 

注：其他synchronized和Lock的詳細說明，小伙伴們自行查閱即可。

本文轉載自微信公眾號「 冰河技術」，可以通過以下二維碼關注。轉載本文請聯系 冰河技術公眾號。