做 iOS 開發(fā)鎖是繞不過去的坎。從synchronized到NSLock、NSRecursiveLock再到pthread_mutex基本能解決絕大多數(shù)多線程互斥問題。但如果你遇到的是“任務(wù)之間有依賴關(guān)系必須等某個條件滿足才能繼續(xù)往下走”這種場景互斥鎖就有點力不從心了。這時候就需要條件鎖NSConditionLock上場。這篇筆記是線程鎖系列的第四篇專門拆解NSConditionLock。先說明一個常見小坑這個類名正確寫法是NSConditionLock中間字母 c 是小寫 c很多人在筆記、代碼注釋、甚至命名文件時隨手寫成NSconditionLock編譯也能過因為 OC 對大小寫敏感如果真的寫錯會直接報錯但項目里駝峰拼寫不規(guī)范容易誤導(dǎo)其他人。這個類在 iOS 底層是基于pthread_mutex和pthread_cond條件變量封裝的它把“鎖”和“條件判斷”綁在了一起讓開發(fā)者能用很直觀的lockWhenCondition:這樣一段代碼實現(xiàn)復(fù)雜的線程協(xié)作。這篇文章適合兩類人一類是剛接觸多線程、被各種鎖繞暈的新手想搞懂條件鎖到底怎么用、和NSCondition有什么區(qū)別另一類是已經(jīng)在項目里用過條件鎖但遇到死鎖、條件不滿足、喚醒丟失等詭異問題想從源碼層面把原理徹底吃透的進階開發(fā)者。我盡量把底層實現(xiàn)和實操場景都講清楚配著代碼一起看會比啃源碼高效得多。1. 從需求倒推到底什么時候非用條件鎖不可1.1 互斥鎖的邊界它能保證“不同時”但保證不了“有先后”先想一個很簡單的業(yè)務(wù)場景直播間里用戶發(fā)送彈幕彈幕需要先經(jīng)過內(nèi)容審核接口審核通過后才能顯示到公屏。如果用NSLock保護彈幕數(shù)組確實能保證多個線程不會同時寫數(shù)組但解決不了“審核完成后才能顯示”這個順序依賴。你可能寫這樣的代碼- (void)handleBarrage:(NSString *)text { [_lock lock]; // 這里只能保護共享資源無法等待審核完成 [_barrageArray addObject:text]; [_lock unlock]; }問題很明顯審核是一個異步過程發(fā)彈幕的線程根本不知道審核什么時候完成。如果強行輪詢檢查審核狀態(tài)既浪費 CPU又容易漏掉狀態(tài)變化?；コ怄i就像一個“單間廁所”——一次只能進一個人但外面排隊的人并不知道廁所里的人什么時候辦完事。條件鎖則更像是“叫號系統(tǒng)”線程可以帶著一個條件去等待直到有人廣播“符合條件的可以進了”。這就是NSConditionLock的核心價值它比互斥鎖多了一個“條件維度”線程不是盲目搶鎖而是先檢查條件值是否匹配不匹配就掛起等待。這種機制天然適合生產(chǎn)者-消費者模型、任務(wù)依賴鏈、緩存預(yù)加載這類場景。1.2 NSConditionLock 的設(shè)計直覺給鎖貼上“門牌號”我第一次看NSConditionLock的文檔時第一反應(yīng)是這玩意兒也太繞了。后來把它類比成“帶門牌號的房間”就好理解了鎖本身有一把同時還有一個整數(shù)值condition相當(dāng)于房間的門牌號。調(diào)用lockWhenCondition:時線程會說“我要求門牌號等于某值才能讓我進去?！比绻坏扔诰€程就在門口掛起等待有人改變門牌號后通知它。unlockWithCondition:則是離開房間前順手把門牌號改成新值并喚醒正在等待的線程。這個設(shè)計把“條件”抽象為一個整數(shù)而不是一個布爾判斷。這個整數(shù)怎么定義完全由業(yè)務(wù)決定0 表示任務(wù)未完成1 表示任務(wù)完成1 表示緩沖區(qū)有空位2 表示緩沖區(qū)已滿諸如此類。和pthread_cond_waitpthread_cond_signal的底層機制相比NSConditionLock最大的優(yōu)勢是封裝了“檢查條件并等待”這個原子過程。底層條件變量最坑的鬼打墻是線程先檢查條件發(fā)現(xiàn)不滿足正要去睡眠時條件恰好被另一個線程滿足并且發(fā)出了信號導(dǎo)致這個線程永遠睡過去。條件鎖幫你把“檢查條件、持有鎖、睡眠、釋放鎖”這幾個動作綁成了一個原子操作從源頭避免這種喚醒丟失問題。2. API 全解析與核心用法2.1 初始化initWithCondition: 的語義NSConditionLock的初始化方法只有一個NSConditionLock *lock [[NSConditionLock alloc] initWithCondition:0];這個condition:參數(shù)代表鎖的初始條件值。你可以理解為房間剛開始掛的門牌號是 0。初始化完成后鎖是未持有的狀態(tài)但條件值已經(jīng)存在。這里有個很多人忽視的細節(jié)初始條件值決定了第一批線程能否立即拿到鎖。舉個例子如果初始化條件設(shè)為 1那么一個線程直接調(diào)用普通的lock方法就能立刻拿到鎖并進入臨界區(qū)。但如果它調(diào)用lockWhenCondition:2即使此刻沒有其他線程持有鎖它也會被掛起因為當(dāng)前條件值不匹配。條件鎖的“鎖”和“條件”是兩套獨立的狀態(tài)機鎖的占用狀態(tài)決定“能不能進房間”條件值決定“門牌號是否符合要求”。只有兩個條件同時滿足線程才能進入臨界區(qū)。設(shè)計初始條件值的時候建議把它定義成你業(yè)務(wù)里最早的那個狀態(tài)。比如任務(wù)剛開始執(zhí)行初始條件為 0任務(wù)執(zhí)行完成條件為 1。這樣一開始等待條件 1 的消費者會正確地進入等待狀態(tài)而不是湊巧“白嫖”了鎖。2.2 lockWhenCondition: 和 unlockWithCondition: 是一對“情侶方法”lockWhenCondition:的完整語義是- (void)lockWhenCondition:(NSInteger)condition;調(diào)用后線程會反復(fù)檢查兩件事鎖是否被占用條件值是否等于傳入的condition。任何一個不滿足線程就阻塞。只有兩個條件同時滿足方法才返回線程正式持有鎖。對應(yīng)的釋放方法- (void)unlockWithCondition:(NSInteger)condition;它做兩件事釋放鎖把鎖的條件值設(shè)為新值。這兩步也是原子的。為什么需要這個方法而不是先unlock再修改條件值因為如果分開做可能出現(xiàn)競態(tài)線程 A 先unlock線程 B 立刻搶到鎖看到了一個舊的、未更新的條件值做了錯誤的判斷。unlockWithCondition:把“釋放鎖”和“更新條件值”打包讓其他線程一拿到鎖就能看到最新的條件值。這里有個經(jīng)典的配對陷阱。如果你用lockWhenCondition:1拿到了鎖但釋放時用了unlockWithCondition:2那么原本在等條件 1 的另一批線程就會被莫名喚醒。示例如下- (void)consumerWork { [_lock lockWhenCondition:1]; // 讀取數(shù)據(jù)處理數(shù)據(jù)... // 錯誤示范應(yīng)該根據(jù)業(yè)務(wù)語義修改條件值 [_lock unlockWithCondition:2]; }假設(shè)消費者只有一個用完數(shù)據(jù)后應(yīng)該把條件恢復(fù)成“緩沖區(qū)有空位”而不是隨手改成 2。條件值一定是你業(yè)務(wù)狀態(tài)的映射不是隨便傳遞的。我建議在項目里用枚舉定義條件值typedef NS_ENUM(NSInteger, BufferState) { BufferStateEmpty 0, BufferStateFull 1, };這樣unlockWithCondition:的參數(shù)語義就非常清晰不會出現(xiàn)“魔法數(shù)字”導(dǎo)致的連環(huán)誤喚醒。2.3 普通 lock/unlock 與 tryLock 家族不要忘記它們的存在除了lockWhenCondition:和unlockWithCondition:NSConditionLock還提供了一組普通方法- (void)lock; - (void)unlock; - (BOOL)tryLock; - (BOOL)tryLockWhenCondition:(NSInteger)condition;lock方法會忽略條件值只要鎖沒被占用就立刻拿到并原封不動保留當(dāng)前的條件值。unlock則只釋放鎖不修改條件值。這兩個方法的存在意味著你可以在條件鎖上執(zhí)行“無條件”的臨界區(qū)代碼。tryLockWhenCondition:特別有意思。它和lockWhenCondition:的區(qū)別是不阻塞立即返回BOOL。如果條件值匹配且鎖未被占用返回YES并持有鎖否則返回NO什么都不做。這種非阻塞變體適合在“能拿到就干活拿不到就干別的”的場景使用例如在列表滾動時試圖預(yù)加載下一批數(shù)據(jù)如果鎖被占用就跳過這輪加載避免卡頓。注意一個細節(jié)tryLock不帶條件版本在鎖被其他線程持有但條件值恰好匹配時會返回NO不會干等。所以它更適合做“機會型”任務(wù)而不是“必須等”的任務(wù)。如果你需要一個帶超時的版本NSConditionLock本身不提供需要用dispatch_semaphore_wait或者pthread_mutex_timedlock實現(xiàn)類似需求。3. 底層實現(xiàn)原理解密3.1 從 GNUstep 源碼看 NSConditionLock 的真身由于NSConditionLock在 Foundation 框架里的實現(xiàn)沒有完全開源我最初是通過 GNUstep 的源碼推斷它的實現(xiàn)結(jié)構(gòu)的。GNUstep 是 Foundation 框架的開源替代實現(xiàn)內(nèi)部邏輯和 Apple 版本高度相似。GNUstep 中NSConditionLock的核心成員只有兩個{ NSInteger _condition_value; NSCondition *_condition; }也就是說它內(nèi)部持有一個NSCondition對象NSCondition封裝了pthread_mutex_tpthread_cond_t和一個NSInteger類型的條件值。這個結(jié)構(gòu)非常樸素但極其關(guān)鍵條件值只是一個普通整數(shù)所有復(fù)雜邏輯都建立在“對這個整數(shù)的讀寫受到鎖保護”這一基礎(chǔ)上。我們拆解lockWhenCondition:的源碼GNUstep 版有刪減- (void)lockWhenCondition: (NSInteger)condition { [_condition lock]; while (condition ! _condition_value) { [_condition wait]; } // 走到這里條件滿足且鎖在手中 }等等你可能注意到一個問題條件滿足后代碼沒有顯式釋放鎖這里的技巧在于NSCondition的wait方法在睡眠時會釋放pthread_mutex被喚醒后會重新獲得鎖。while 循環(huán)每次都重新檢查條件如果條件不滿足會再次wait再次釋放鎖直到條件滿足跳出循環(huán)。跳出循環(huán)時線程仍然持有pthread_mutex也就是鎖還在手中。所以lockWhenCondition:返回后你已經(jīng)持有了鎖可以直接進入臨界區(qū)。對應(yīng)的釋放方法- (void)unlockWithCondition: (NSInteger)condition { [_condition lock]; _condition_value condition; [_condition broadcast]; [_condition unlock]; }這段代碼同樣清晰先拿到鎖pthread_mutex修改條件值然后broadcast喚醒所有等待線程最后釋放鎖?？吹竭@里你應(yīng)該明白NSConditionLock本質(zhì)上就是NSCondition 條件值判斷的語法糖。3.2 條件變量的“廣播”語義為什么是 broadcast 而不是 signalNSCondition的broadcast方法對應(yīng)底層pthread_cond_broadcast會喚醒所有等待在該條件上的線程signal對應(yīng)pthread_cond_signal只喚醒一個線程。為什么NSConditionLock的unlockWithCondition:要用broadcast而不是signal因為當(dāng)條件值變化后無法確定哪個等待線程會受益于這個變化。假設(shè)三個線程分別等待條件 1、條件 2、條件 3你把條件值從 0 改成 2那么等待條件 2 的線程應(yīng)該被喚醒。但如果只喚醒一個線程而恰好喚醒的是等待條件 1 的線程它醒來后發(fā)現(xiàn)條件不匹配只能再次睡回去白白浪費一次調(diào)度。用broadcast則是簡單粗暴的喚醒所有人讓每個線程自己檢查條件是否匹配。不匹配就繼續(xù)睡匹配的就搶鎖干活。代價是可能引起“驚群效應(yīng)”多個線程同時被喚醒但只有一個能搶到鎖不過在pthread_cond的底層調(diào)度中這個開銷在現(xiàn)代系統(tǒng)上已經(jīng)優(yōu)化得很低可以接受。理解了這一點再看NSConditionLock的喚醒過程就通透很多它不關(guān)心誰在等什么條件只是把消息廣而告之讓感興趣的線程自己來認領(lǐng)。這也解釋了為什么條件值最好用少量、明確的枚舉——等待的線程越多廣播時的無效喚醒就越多性能邊際越低。3.3 和 NSCondition 對比什么時候用誰NSCondition和NSConditionLock是對新手殺傷力最大的兩個類名字極其相似用法卻完全不同。我做了個對比表維度NSConditionNSConditionLock核心機制wait / signal 手動配對lockWhenCondition: / unlockWithCondition: 自動配對條件表示謂詞邏輯需自己 while 循環(huán)判斷整數(shù)值相等判斷喚醒方式signal 喚醒一個 / broadcast 喚醒全部固定 broadcast臨界區(qū)保護需要手動加鎖wait 自動釋放鎖獲取鎖后自動進入臨界區(qū)上手難度容易踩坑while 循環(huán)忘記寫、signal 丟失直觀條件值匹配即可適用場景單生產(chǎn)者單消費者、精細控制多條件分流、任務(wù)依賴舉個例子實現(xiàn)一個簡單的“等待數(shù)據(jù)到位再處理”的模型用NSCondition需要這樣寫NSCondition *condition [[NSCondition alloc] init]; BOOL dataReady NO; // 消費者 [condition lock]; while (!dataReady) { [condition wait]; } // 處理數(shù)據(jù)... [condition unlock];而用NSConditionLock直接寫成NSConditionLock *lock [[NSConditionLock alloc] initWithCondition:0]; // 消費者 [lock lockWhenCondition:1]; // 處理數(shù)據(jù)... [lock unlockWithCondition:0];后者明顯更簡潔而且不容易漏寫 while 循環(huán)。但要注意NSCondition能用謂詞表達任意復(fù)雜條件例如data.count 10 hasMoreDataNSConditionLock只能表達整數(shù)相等。如果你需要的條件是復(fù)合邏輯條件鎖反而會限制表達力這時候老老實實用NSCondition更合適。4. 兩個典型場景的完整落地4.1 生產(chǎn)者-消費者模型用條件鎖替代信號量生產(chǎn)者-消費者是最經(jīng)典的多線程協(xié)作問題。假設(shè)有一個共享緩沖區(qū)數(shù)組生產(chǎn)者往里放數(shù)據(jù)消費者從這里取數(shù)據(jù)。緩沖區(qū)為空時消費者要等待緩沖區(qū)滿時生產(chǎn)者要等待。我先給出完整可運行的示例。定義兩個條件值空和滿。但發(fā)現(xiàn)一個尷尬的問題——條件鎖只能存一個整數(shù)值無法同時表達“空”和“滿”兩個狀態(tài)。如果用 0 表示空、1 表示滿生產(chǎn)者生產(chǎn)完設(shè)置成滿消費者消費完設(shè)置成空同一時間只可能是一個狀態(tài)兩個線程就能配合起來。但緩沖區(qū)容量大于 1 時比如可以放 5 個數(shù)據(jù)只用兩個狀態(tài)就不夠精確了。此時建議用“計數(shù)”來建模條件值直接等于緩沖區(qū)里的數(shù)據(jù)個數(shù)。生產(chǎn)者每放入一個數(shù)據(jù)條件值加 1消費者每取走一個數(shù)據(jù)條件值減 1。消費者等到條件值 0 時取數(shù)據(jù)生產(chǎn)者等到條件值 capacity 時放數(shù)據(jù)。問題來了NSConditionLock只能判斷“等于”無法判斷“大于”或“小于”。如果用條件鎖實現(xiàn)我們需要枚舉所有可能的計數(shù)狀態(tài)。假設(shè) capacity 5就定義 6 個狀態(tài)0~5。生產(chǎn)者填充后把條件值設(shè)為新的計數(shù)消費者同樣更新計數(shù)。實測下來這種寫法在 capacity 較大的時候不太優(yōu)雅。條件數(shù)膨脹代碼可讀性下降。實際情況里如果緩沖區(qū)容量不大比如 2 或 3還能接受容量一大我建議改用dispatch_semaphore或者NSCondition配合謂詞。這也呼應(yīng)了前面說的條件鎖適合“條件狀態(tài)數(shù)量有限且明確”的場景不擅長“區(qū)間判斷”場景。4.2 任務(wù)按序執(zhí)行A 完成才能執(zhí)行 BB 完成才能執(zhí)行 C條件鎖最有價值的地方是表達任務(wù)依賴鏈。假設(shè)有三個任務(wù)任務(wù) A 執(zhí)行完才能執(zhí)行 BB 執(zhí)行完才能執(zhí)行 C。用條件鎖寫非常清晰typedef NS_ENUM(NSInteger, TaskState) { TaskStateIdle 0, TaskStateAFinished 1, TaskStateBFinished 2, TaskStateCFinished 3, }; NSConditionLock *lock [[NSConditionLock alloc] initWithCondition:TaskStateIdle]; // 任務(wù) A - (void)taskA { // 模擬耗時操作 sleep(1); NSLog(Task A done); [lock unlockWithCondition:TaskStateAFinished]; } // 任務(wù) B - (void)taskB { [lock lockWhenCondition:TaskStateAFinished]; sleep(1); NSLog(Task B done); [lock unlockWithCondition:TaskStateBFinished]; } // 任務(wù) C - (void)taskC { [lock lockWhenCondition:TaskStateBFinished]; sleep(1); NSLog(Task C done); [lock unlockWithCondition:TaskStateCFinished]; }這里其實不需要單獨的taskA獲取鎖因為 A 是最早的任務(wù)沒有前置條件。直接執(zhí)行完就用unlockWithCondition:修改條件值。B 和 C 則在對應(yīng)的條件值處等待。還要注意一個細節(jié)A 調(diào)用unlockWithCondition:時如果 A 之前沒有獲得過鎖會發(fā)生什么來看源碼unlockWithCondition:的第一步是[_condition lock]也就是它會自己先獲取鎖再設(shè)置條件值再廣播再釋放。所以無論 A 之前有沒有持有鎖都能正確執(zhí)行。這意味著任務(wù)鏈的起點可以用一個“從未加鎖”的unlockWithCondition:來啟動后續(xù)任務(wù)。這也是NSConditionLock被設(shè)計得比較寬松的一點和NSLock的嚴(yán)格配對不同只要語義清晰不必拘泥于成對調(diào)用。但我不建議把這個寬松當(dāng)成常態(tài)。除了鏈條起點這種特殊情況其他環(huán)節(jié)最好保證lockWhenCondition:與unlockWithCondition:成對出現(xiàn)邏輯才不容易混亂。4.3 多生產(chǎn)多消費時的注意點實際項目中不太可能只有一個生產(chǎn)者和一個消費者。多生產(chǎn)多消費時條件鎖仍然能工作但有幾個值得注意的坑。第一個坑是“條件值被覆蓋”。假設(shè)生產(chǎn)者 A 和 B 同時往緩沖區(qū)寫數(shù)據(jù)A 寫完后執(zhí)行unlockWithCondition:1B 寫完后執(zhí)行unlockWithCondition:2。理論上來說這兩個條件是等價的但消費者可能在 A 寫完、B 沒寫完時就被喚醒并且去執(zhí)行了因為它看到的條件值是 1已經(jīng)滿足。如果你的業(yè)務(wù)要求“兩個生產(chǎn)者都寫完才能開始消費”那這個邏輯就不對需要改成條件 2 表示“兩個生產(chǎn)者都完成”A 和 B 寫完后都執(zhí)行unlockWithCondition:1再由某一方在確認都完成后置為 2。這類狀態(tài)聚合邏輯建議單獨用一個狀態(tài)管理類而不是靠條件鎖的整數(shù)值硬啃。第二個坑是“同一個條件值被重復(fù)設(shè)置”。當(dāng)消費者消費完執(zhí)行unlockWithCondition:0而另一個消費者同時也在等條件 1這沒問題。但如果有兩個消費者都調(diào)用unlockWithCondition:0第二次設(shè)置就是重復(fù)的可能引起額外的喚醒。這一般不是致命問題但在高性能路徑上會浪費調(diào)度。我見過一個線上項目日志里條件鎖的廣播頻率比實際任務(wù)頻率高了幾倍就是因為多個線程都執(zhí)行了重復(fù)的unlockWithCondition:。當(dāng)然重復(fù)調(diào)用不會產(chǎn)生死鎖最壞情況只是多余的上下文切換。第三個坑是“鎖的公平性”。NSConditionLock不保證公平性也就是說先等待的線程不一定先喚醒。被喚醒的線程要重新競爭pthread_mutex而調(diào)度器沒有義務(wù)按等待順序分配鎖。如果業(yè)務(wù)強依賴“先來先服務(wù)”條件鎖并不合適你需要用 FIFO 隊列自己控制順序或者用pthread_mutex 優(yōu)先級隊列的思路。5. 經(jīng)典誤用與排查實錄5.1 死鎖三兄弟互相等待、條件斷鏈、漏喚醒我整理了三種我自己踩過或幫別人排查過的條件鎖死鎖模式每種都對應(yīng)一個真實的“事故現(xiàn)場”。模式一交叉等待ABBA 死鎖。線程 A 持有鎖 L1等待條件 C1線程 B 持有鎖 L2等待條件 C2。但 C1 的解鎖條件需要 B 釋放C2 的解鎖條件需要 A 釋放兩者互相死不撒手。條件鎖本身不解決鎖順序問題只要代碼里出現(xiàn)了“持有一把鎖再去申請另一把鎖/條件”就要警惕循環(huán)等待。排查思路是畫出線程的持有和等待圖找出環(huán)路強制約定加鎖順序。模式二條件斷鏈。生產(chǎn)者把所有工作做完后忘了調(diào)用unlockWithCondition:而是調(diào)用了普通的unlock。條件值永遠停在初始狀態(tài)所有等待線程直接永久等待。這是我見過最多的低級錯誤。代碼審查時特別留意lockWhenCondition:對應(yīng)的釋放語句條件值是否真的更新了。模式三漏喚醒。開發(fā)者想當(dāng)然地認為“條件值已經(jīng)被外面改了等待線程會被自動喚醒”。自作主張地在別的線程直接修改條件值而不走unlockWithCondition:這在NSConditionLock里其實做不到因為condition屬性是readonly的。但也有人為了繞過限制直接用 KVC 去改私有成員引發(fā)各種奇奇怪怪的行為。我說句實在話條件鎖的喚醒只能通過unlockWithCondition:或broadcast完成任何繞過這個機制的花招都是在給自己埋雷。5.2 unlockWithCondition: 的條件值連環(huán)反應(yīng)unlockWithCondition:會修改條件值這本身是設(shè)計好的但它會引起“連環(huán)反應(yīng)”線程 A 設(shè)置條件 1喚醒等待條件 1 的線程 BB 執(zhí)行完后設(shè)置條件 2喚醒等待條件 2 的線程 C。這條鏈如果符合業(yè)務(wù)預(yù)期就沒問題最怕的是條件值設(shè)置不當(dāng)把多個等待組的線程同時喚醒。舉個例子線程 A 等待條件 1線程 B 等待條件 2。某個線程執(zhí)行unlockWithCondition:1只應(yīng)該喚醒 A。但如果之前有人把條件值改成 3而 A 和 B 都在等 1 和 2它們都不會被喚醒直到有人把條件值調(diào)回 1 或 2。這種“條件值漂移”會讓等待線程的喚醒時間變得不確定排查起來特別折磨人因為代碼看起來邏輯都對但就是偶發(fā)卡頓。我的建議是條件值的設(shè)置必須只在固定的幾個位置如任務(wù)狀態(tài)轉(zhuǎn)換點進行而且最好用枚舉表示禁止裸傳整數(shù)。如果條件值需要增減比如用計數(shù)表示狀態(tài)一定要保證增減的原子性——這一點在條件鎖內(nèi)部是安全的因為unlockWithCondition:整個操作持鎖不需要額外保護。5.3 性能實測與選型建議用NSConditionLock最常被問的問題就是它性能到底怎么樣說實話條件鎖的性能在 iOS 鎖家族里屬于中上水平極端對比下dispatch_semaphore或os_unfair_lock會更快。我模擬過 10 萬次生產(chǎn)者-消費者交替執(zhí)行條件鎖和裸寫pthread_mutex pthread_cond的耗時差異在 5% 以內(nèi)和NSLock也比不出明顯差距。性能關(guān)鍵不在于鎖本身的實現(xiàn)而在于你怎么用它。濫用broadcast喚醒大量無關(guān)線程、在鎖內(nèi)部做耗時操作比如磁盤 IO、網(wǎng)絡(luò)請求、頻繁設(shè)置條件值導(dǎo)致反復(fù)喚醒這些都是性能殺手。鎖內(nèi)的臨界區(qū)代碼務(wù)必精簡到最小所有 I/O 都挪到鎖外執(zhí)行。選型上我的建議是任務(wù)依賴、按條件分流首選NSConditionLock。一對一的等待通知如異步任務(wù)完成回調(diào)用dispatch_semaphore或NSCondition更直接。復(fù)雜謂詞條件比如多個變量構(gòu)成的狀態(tài)用NSCondition while 循環(huán)。高性能計數(shù)器場景直接用os_unfair_lock或std::atomic。NSConditionLock不是萬能鑰匙但它是“條件等待”這個需求里最貼近直覺的抽象。只要條件狀態(tài)數(shù)量可控、狀態(tài)轉(zhuǎn)換路徑清晰它能讓多線程代碼的意圖讀起來像單線程一樣順暢。我個人在實際項目里用得最多的地方是啟動流程的任務(wù)編排——好幾個模塊要并行初始化但部分模塊有依賴關(guān)系用條件鎖描述“哪個模塊完成后才能啟動下一個模塊”非常直觀。如果你也遇到類似的“必須等某件事完成才能繼續(xù)”的并發(fā)場景不妨先把條件狀態(tài)枚舉設(shè)計好再用NSConditionLock把流程串起來。