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