和朋友聊天他提到：ReentrantLock 的構(gòu)造函數(shù)可以傳遞一個(gè) bool 數(shù)據(jù)，true 時(shí)構(gòu)造的是“公平鎖”、false 時(shí)構(gòu)造的是“非公平鎖”。

我的印象中鎖是不區(qū)分類型的，所以認(rèn)為這應(yīng)該是 Java 發(fā)明的概念，于是就惡補(bǔ)了一下。

[[238481]]

鎖的底層實(shí)現(xiàn)

無論什么語言在操作系統(tǒng)層面鎖的操作都會(huì)變成系統(tǒng)調(diào)用(System Call)，以 Linux 為例，就是 futex 函數(shù)，可以把它理解為兩個(gè)函數(shù)： futex_wait(s)，對(duì)變量 s 加鎖;futex_wake(s)釋放 s 上的鎖，喚醒其他線程。

如果你熟悉操作系統(tǒng)原理其實(shí)就是 P/V 操作。

Java 公平鎖和非公平鎖

公平鎖的 lock 操作是調(diào)用futex_wait，unlock 操作是調(diào)用futex_wake。比如下面的代碼

非公平鎖的 lock/unlock 操作會(huì)先做一次 CAS 操作然后再調(diào)用 futex_wait、futex_wake。比如下面的代碼

在上鎖之前增加了一個(gè) CAS 原子操作，它接受三個(gè)變量可以把它理解為下面的邏輯：

***個(gè)參數(shù)的值和第二個(gè)參數(shù)不相等則返回 0 表示操作失敗否則更新為新的值。這個(gè)函數(shù)不是由代碼實(shí)現(xiàn)的而是 CPU 提供的一個(gè)指令，比如 Intel 的叫 cmpxchg;高級(jí)語言進(jìn)行了封裝，比如 Java 的 Atomic 變量。

為什么

明白了原理再來提問為什么，在上鎖之前先通過 CAS 修改一個(gè)變量表示“我要上鎖”了看似很冗余的操作，其實(shí)它是一次自旋，如果資源很快被使用完可以提高系統(tǒng)的吞吐率?？紤]下面的場景

上鎖之前的時(shí)間是 t1，上鎖之后是 t2(使用資源)，釋放鎖是 t3。

現(xiàn)在有兩個(gè)線程，處于 t1 狀態(tài)，其中 A 線程先搶到資源處于 t2 ;B 線程也會(huì)嘗試 lock，與此同時(shí) t2 釋放了，而 lock 動(dòng)作也執(zhí)行成功了 B 被掛起;系統(tǒng)繼續(xù)執(zhí)行 A 釋放成功喚醒 B 繼續(xù)執(zhí)行。

上述過程中 B 只要再多等待“一丟丟”就不用被掛起，直接獲得資源繼續(xù)執(zhí)行。非公平鎖的 CAS 操作就是為了增加一丟丟時(shí)間。

采用非公平鎖，如果系統(tǒng)中有 3 個(gè)線程執(zhí)行，A 搶到資源，C 沒有搶到處于掛起狀態(tài)，此時(shí) B 嘗試 CAS 操作，而 A 剛好釋放掉資源還沒有來得及喚醒 C，那么 B 會(huì)先搶到資源，在 C 之前執(zhí)行。這就是“非公平”的來歷，雖然 C 老老實(shí)實(shí)的等待了很長時(shí)間，但是 B 的“時(shí)機(jī)”把握的好，迅速“插隊(duì)”完成資源搶占。

總結(jié)

上鎖的過程本身也是有時(shí)間開銷的，如果操作資源的時(shí)間比上鎖的時(shí)間還短建議使用非公平鎖可以提高系統(tǒng)的吞吐率;否則就老老實(shí)實(shí)的用公平鎖。

【本文是51CTO專欄作者“邢森”的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)聯(lián)系作者本人獲取授權(quán)】

戳這里，看該作者更多好文