自Java 5 開始，java.util.concurrent.locks 包中包含了一些鎖的實現，因此你不用去實現自己的鎖了。但是你仍然需要去了解怎樣使用這些鎖。
一個簡單的鎖
讓我們從java 中的一個同步塊開始：
public class Counter{ private int count = 0; public int inc(){ synchronized(this){ return ++count; } }}可以看到在inc()方法中有一個synchronized(this)代碼塊。該代碼塊可以保證在同一時間只有一個線程可以執行return ++count。雖然在synchronized 的同步塊中的代碼可以更加複雜，但是++count 這種簡單的操作已經足以表達出線程同步的意思。
以下的Counter 類用Lock 代替synchronized 達到了同樣的目的：
public class Counter{ private Lock lock = new Lock(); private int count = 0; public int inc(){ lock.lock(); int newCount = ++count; lock.unlock(); return newCount; }}lock()方法會對Lock 實例對象進行加鎖，因此所有對該對象調用lock()方法的線程都會被阻塞，直到該Lock 對象的unlock()方法被調用。
這裡有一個Lock 類的簡單實現：
public class Counter{public class Lock{ private boolean isLocked = false; public synchronized void lock() throws InterruptedException{ while(isLocked){ wait(); } isLocked = true; } public synchronized void unlock(){ isLocked = false; notify(); }}注意其中的while(isLocked)循環，它又被叫做“自旋鎖”。當isLocked 為true 時，調用lock()的線程在wait()調用上阻塞等待。為防止該線程沒有收到notify()調用也從wait()中返回（也稱作虛假喚醒），這個線程會重新去檢查isLocked 條件以決定當前是否可以安全地繼續執行還是需要重新保持等待，而不是認為線程被喚醒了就可以安全地繼續執行了。如果isLocked 為false，當前線程會退出while(isLocked)循環，並將isLocked 設回true，讓其它正在調用lock()方法的線程能夠在Lock 實例上加鎖。
當線程完成了臨界區（位於lock()和unlock()之間）中的代碼，就會調用unlock()。執行unlock()會重新將isLocked 設置為false，並且通知（喚醒）其中一個（若有的話）在lock()方法中調用了wait()函數而處於等待狀態的線程。
鎖的可重入性
Java 中的synchronized 同步塊是可重入的。這意味著如果一個java 線程進入了代碼中的synchronized 同步塊，並因此獲得了該同步塊使用的同步對像對應的管程上的鎖，那麼這個線程可以進入由同一個管程對象所同步的另一個java 代碼塊。下面是一個例子：
public class Reentrant{ public synchronized outer(){ inner(); } public synchronized inner(){ //do something }}注意outer()和inner()都被聲明為synchronized，這在Java 中和synchronized(this)塊等效。如果一個線程調用了outer()，在outer()裡調用inner()就沒有什麼問題，因為這兩個方法（代碼塊）都由同一個管程對象（”this”)所同步。如果一個線程已經擁有了一個管程對像上的鎖，那麼它就有權訪問被這個管程對象同步的所有代碼塊。這就是可重入。線程可以進入任何一個它已經擁有的鎖所同步著的代碼塊。
前面給出的鎖實現不是可重入的。如果我們像下面這樣重寫Reentrant 類，當線程調用outer()時，會在inner()方法的lock.lock()處阻塞住。
public class Reentrant2{ Lock lock = new Lock(); public outer(){ lock.lock(); inner(); lock.unlock(); } public synchronized inner(){ lock.lock(); //do something lock.unlock(); }}調用outer()的線程首先會鎖住Lock 實例，然後繼續調用inner()。 inner()方法中該線程將再一次嘗試鎖住Lock 實例，結果該動作會失敗（也就是說該線程會被阻塞），因為這個Lock 實例已經在outer()方法中被鎖住了。
兩次lock()之間沒有調用unlock()，第二次調用lock 就會阻塞，看過lock()實現後，會發現原因很明顯：
public class Lock{ boolean isLocked = false; public synchronized void lock() throws InterruptedException{ while(isLocked){ wait(); } isLocked = true; } ...}一個線程是否被允許退出lock()方法是由while 循環（自旋鎖）中的條件決定的。當前的判斷條件是只有當isLocked 為false 時lock 操作才被允許，而沒有考慮是哪個線程鎖住了它。
為了讓這個Lock 類具有可重入性，我們需要對它做一點小的改動：
public class Lock{ boolean isLocked = false; Thread lockedBy = null; int lockedCount = 0; public synchronized void lock() throws InterruptedException{ Thread callingThread = Thread.currentThread(); while(isLocked && lockedBy != callingThread){ wait(); } isLocked = true; lockedCount++; lockedBy = callingThread; } public synchronized void unlock(){ if(Thread.curentThread() == this.lockedBy){ lockedCount--; if(lockedCount == 0){ isLocked = false; notify(); } } } ...}注意到現在的while 循環（自旋鎖）也考慮到了已鎖住該Lock 實例的線程。如果當前的鎖對像沒有被加鎖(isLocked = false)，或者當前調用線程已經對該Lock 實例加了鎖，那麼while 循環就不會被執行，調用lock()的線程就可以退出該方法（譯者註：“被允許退出該方法”在當前語義下就是指不會調用wait()而導致阻塞）。
除此之外，我們需要記錄同一個線程重複對一個鎖對象加鎖的次數。否則，一次unblock()調用就會解除整個鎖，即使當前鎖已經被加鎖過多次。在unlock()調用沒有達到對應lock()調用的次數之前，我們不希望鎖被解除。
現在這個Lock 類就是可重入的了。
鎖的公平性
Java 的synchronized 塊並不保證嘗試進入它們的線程的順序。因此，如果多個線程不斷競爭訪問相同的synchronized 同步塊，就存在一種風險，其中一個或多個線程永遠也得不到訪問權―― 也就是說訪問權總是分配給了其它線程。這種情況被稱作線程飢餓。為了避免這種問題，鎖需要實現公平性。本文所展現的鎖在內部是用synchronized 同步塊實現的，因此它們也不保證公平性。
在finally 語句中調用unlock()
如果用Lock 來保護臨界區，並且臨界區有可能會拋出異常，那麼在finally 語句中調用unlock()就顯得非常重要了。這樣可以保證這個鎖對象可以被解鎖以便其它線程能繼續對其加鎖。以下是一個示例：
lock.lock();try{ //do critical section code, //which may throw exception} finally { lock.unlock();}這個簡單的結構可以保證當臨界區拋出異常時Lock 對象可以被解鎖。如果不是在finally 語句中調用的unlock()，當臨界區拋出異常時，Lock 對象將永遠停留在被鎖住的狀態，這會導致其它所有在該Lock 對像上調用lock()的線程一直阻塞。
以上就是關於java 多線程鎖的資料整理，後續繼續補充相關資料，謝謝大家對本站的支持！