public ReentrantLock() {

       sync = new NonfairSync();

}

 public ReentrantLock(boolean fair) {
          sync = fair ? new FairSync() : new NonfairSync();
    }

在公平的鎖上，執行緒按照他們發出請求的順序獲取鎖，但在非公平鎖上，則允許‘插隊’：當一個執行緒請求非公平鎖時，如果在發出請求的同時該鎖變成可用狀態，那麼這個執行緒會跳過佇列中所有的等待執行緒而獲得鎖。     非公平的ReentrantLock 並不提倡 插隊行為，但是無法防止某個執行緒在合適的時候進行插隊。

在公平的鎖中，如果有另一個執行緒持有鎖或者有其他執行緒在等待佇列中等待這個所，那麼新發出的請求的執行緒將被放入到佇列中。而非公平鎖上，只有當鎖被某個執行緒持有時，新發出請求的執行緒才會被放入佇列中。

非公平鎖效能高於公平鎖效能的原因：

在恢復一個被掛起的執行緒與該執行緒真正執行之間存在著嚴重的延遲。

假設執行緒A持有一個鎖，並且執行緒B請求這個鎖。由於鎖被A持有，因此B將被掛起。當A釋放鎖時，B將被喚醒，因此B會再次嘗試獲取這個鎖。與此同時，如果執行緒C也請求這個鎖，那麼C很可能會在B被完全喚醒之前獲得、使用以及釋放這個鎖。這樣就是一種雙贏的局面：B獲得鎖的時刻並沒有推遲，C更早的獲得了鎖，並且吞吐量也提高了。

當持有鎖的時間相對較長或者請求鎖的平均時間間隔較長，應該使用公平鎖。在這些情況下，插隊帶來的吞吐量提升（當鎖處於可用狀態時，執行緒卻還處於被喚醒的過程中）可能不會出現。