總括：
在Java的ReentrantLock構造函數中提供了兩種鎖：創建公平鎖和非公平鎖（默認）。代碼如下：
}
public ReentrantLock() {
sync = new NonfairSync();}
在公平的鎖上，線程按照他們發出請求的順序獲取鎖，但在非公平鎖上，則允許‘插隊’：當一個線程請求非公平鎖時，如果在發出請求的同時該鎖變成可用狀態，那麼這個線程會跳過隊列中所有的等待線程而獲得鎖。 非公平的ReentrantLock 並不提倡 插隊行爲，但是無法防止某個線程在合適的時候進行插隊。
在公平的鎖中，如果有另一個線程持有鎖或者有其他線程在等待隊列中等待這個所，那麼新發出的請求的線程將被放入到隊列中。而非公平鎖上，只有當鎖被某個線程持有時，新發出請求的線程纔會被放入隊列中。
非公平鎖性能高於公平鎖性能的原因：
在恢復一個被掛起的線程與該線程真正運行之間存在着嚴重的延遲。
假設線程A持有一個鎖，並且線程B請求這個鎖。由於鎖被A持有，因此B將被掛起。當A釋放鎖時，B將被喚醒，因此B會再次嘗試獲取這個鎖。與此同時，如果線程C也請求這個鎖，那麼C很可能會在B被完全喚醒之前獲得、使用以及釋放這個鎖。這樣就是一種雙贏的局面：B獲得鎖的時刻並沒有推遲，C更早的獲得了鎖，並且吞吐量也提高了。
當持有鎖的時間相對較長或者請求鎖的平均時間間隔較長，應該使用公平鎖。在這些情況下，插隊帶來的吞吐量提升（當鎖處於可用狀態時，線程卻還處於被喚醒的過程中）可能不會出現。