一.Java多執行緒可以通過：

1. synchronized關鍵字

2. Java.util.concurrent包中的lock介面和ReentrantLock實現類

這兩種方式實現加鎖。

二.synchronized關鍵字加鎖的缺陷：

如果一個程式碼塊被synchronized修飾了，當一個執行緒獲取了對應的鎖，並執行該程式碼塊時，其他執行緒便只能一直等待，等待獲取鎖的執行緒釋放鎖，而這裡獲取鎖的執行緒釋放鎖只會有兩種情況：

　　1）獲取鎖的執行緒執行完了該程式碼塊，然後執行緒釋放對鎖的佔有；

　　2）執行緒執行發生異常，此時JVM會讓執行緒自動釋放鎖。

　　那麼如果這個獲取鎖的執行緒由於要等待IO或者其他原因（比如呼叫sleep方法）被阻塞了，但是又沒有釋放鎖，其他執行緒便只能乾巴巴地等待，試想一下，這多麼影響程式執行效率。

　　因此就需要有一種機制可以不讓等待的執行緒一直無期限地等待下去（比如只等待一定的時間或者能夠響應中斷），通過Lock就可以辦到。

　　再舉個例子：當有多個執行緒讀寫檔案時，讀操作和寫操作會發生衝突現象，寫操作和寫操作會發生衝突現象，但是讀操作和讀操作不會發生衝突現象。

　　但是採用synchronized關鍵字來實現同步的話，就會導致一個問題：

　　如果多個執行緒都只是進行讀操作，所以當一個執行緒在進行讀操作時，其他執行緒只能等待無法進行讀操作。

　　因此就需要一種機制來使得多個執行緒都只是進行讀操作時，執行緒之間不會發生衝突，通過Lock就可以辦到。

　　另外，通過Lock可以知道執行緒有沒有成功獲取到鎖。這個是synchronized無法辦到的。

   　1）Lock不是Java語言內建的，synchronized是Java語言的關鍵字，因此是內建特性。Lock是一個類，通過這個類可以實現同步訪問；

　　2）Lock和synchronized有一點非常大的不同，採用synchronized不需要使用者去手動釋放鎖，當synchronized方法或者synchronized程式碼塊執行完之後，系統會自動讓執行緒釋放對鎖的佔用；而Lock則必須要使用者去手動釋放鎖，如果沒有主動釋放鎖，就有可能導致出現死鎖現象。

三.Lock和synchronized的選擇：

　　總結來說，Lock和synchronized有以下幾點不同：

　　1）Lock是一個介面，而synchronized是Java中的關鍵字，synchronized是內建的語言實現；

　　2）synchronized在發生異常時，會自動釋放執行緒佔有的鎖，因此不會導致死鎖現象發生；而Lock在發生異常時，如果沒有主動通過unLock()去釋放鎖，則很可能造成死鎖現象，因此使用Lock時需要在finally塊中釋放鎖；

　　3）Lock可以讓等待鎖的執行緒響應中斷，而synchronized卻不行，使用synchronized時，等待的執行緒會一直等待下去，不能夠響應中斷；（I/O和Synchronized都能相應中斷，即不需要處理interruptionException異常）

　　4）通過Lock可以知道有沒有成功獲取鎖，而synchronized卻無法辦到。

　　5）Lock可以提高多個執行緒進行讀操作的效率。

　　在效能上來說，如果競爭資源不激烈，兩者的效能是差不多的，而當競爭資源非常激烈時（即有大量執行緒同時競爭），此時Lock的效能要遠遠優於synchronized。所以說，在具體使用時要根據適當情況選擇。

四. 鎖的種類介紹：

在前面介紹了Lock的基本使用，這一節來介紹一下與鎖相關的幾個概念。

　　1.可重入鎖

　　如果鎖具備可重入性，則稱作為可重入鎖。像synchronized和ReentrantLock都是可重入鎖，可重入性在我看來實際上表明瞭鎖的分配機制：基於執行緒的分配，而不是基於方法呼叫的分配。舉個簡單的例子，當一個執行緒執行到某個synchronized方法時，比如說method1，而在method1中會呼叫另外一個synchronized方法method2，此時執行緒不必重新去申請鎖，而是可以直接執行方法method2。

　　看下面這段程式碼就明白了：

 　　上述程式碼中的兩個方法method1和method2都用synchronized修飾了，假如某一時刻，執行緒A執行到了method1，此時執行緒A獲取了這個物件的鎖，而由於method2也是synchronized方法，假如synchronized不具備可重入性，此時執行緒A需要重新申請鎖。但是這就會造成一個問題，因為執行緒A已經持有了該物件的鎖，而又在申請獲取該物件的鎖，這樣就會執行緒A一直等待永遠不會獲取到的鎖。

　　而由於synchronized和Lock都具備可重入性，所以不會發生上述現象。

　　2.可中斷鎖

　　可中斷鎖：顧名思義，就是可以相應中斷的鎖。

　　在Java中，synchronized就不是可中斷鎖，而Lock是可中斷鎖。

　　如果某一執行緒A正在執行鎖中的程式碼，另一執行緒B正在等待獲取該鎖，可能由於等待時間過長，執行緒B不想等待了，想先處理其他事情，我們可以讓它中斷自己或者在別的執行緒中中斷它，這種就是可中斷鎖。

　　在前面演示lockInterruptibly()的用法時已經體現了Lock的可中斷性。

　　3.公平鎖

　　公平鎖即儘量以請求鎖的順序來獲取鎖。比如同是有多個執行緒在等待一個鎖，當這個鎖被釋放時，等待時間最久的執行緒（最先請求的執行緒）會獲得該所，這種就是公平鎖。

　　非公平鎖即無法保證鎖的獲取是按照請求鎖的順序進行的。這樣就可能導致某個或者一些執行緒永遠獲取不到鎖。

　　在Java中，synchronized就是非公平鎖，它無法保證等待的執行緒獲取鎖的順序。

　　而對於ReentrantLock和ReentrantReadWriteLock，它預設情況下是非公平鎖，但是可以設定為公平鎖。

　　看一下這2個類的原始碼就清楚了：

　　在ReentrantLock中定義了2個靜態內部類，一個是NotFairSync，一個是FairSync，分別用來實現非公平鎖和公平鎖。

　　我們可以在建立ReentrantLock物件時，通過以下方式來設定鎖的公平性：

 　　如果引數為true表示為公平鎖，為fasle為非公平鎖。預設情況下，如果使用無參構造器，則是非公平鎖。

　　另外在ReentrantLock類中定義了很多方法，比如：

　　isFair()        //判斷鎖是否是公平鎖

　　isLocked()    //判斷鎖是否被任何執行緒獲取了

　　isHeldByCurrentThread()   //判斷鎖是否被當前執行緒獲取了

　　hasQueuedThreads()   //判斷是否有執行緒在等待該鎖

　　在ReentrantReadWriteLock中也有類似的方法，同樣也可以設定為公平鎖和非公平鎖。不過要記住，ReentrantReadWriteLock並未實現Lock介面，它實現的是ReadWriteLock介面。

　　4.讀寫鎖

　　讀寫鎖將對一個資源（比如檔案）的訪問分成了2個鎖，一個讀鎖和一個寫鎖。

　　正因為有了讀寫鎖，才使得多個執行緒之間的讀操作不會發生衝突。

　　ReadWriteLock就是讀寫鎖，它是一個介面，ReentrantReadWriteLock實現了這個介面。

　　可以通過readLock()獲取讀鎖，通過writeLock()獲取寫鎖。

ReadWriteLock

　　ReadWriteLock也是一個介面，在它裡面只定義了兩個方法：