上一節(jié)對(duì)鎖家族的@synchronized進(jìn)行源碼解析固耘，本節(jié)將對(duì)鎖家族的其他2位NSLock和NSCondition進(jìn)行源碼分析题篷。
-
鎖家族全家福（耗時(shí)圖）：
image.png
- NSLock應(yīng)用與源碼
- NSLock、NSRecursiveLock厅目、@synchronized三者的區(qū)別
- NSCondition
- NSConditionLock
1. NSLock
- 測(cè)試代碼
@interface ViewController ()
@property (nonatomic, strong) NSMutableArray *testArray;
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
[self demo];
}
- (void)demo {
NSLog(@"123");
self.testArray = [NSMutableArray array];
NSLock * lock = [[NSLock alloc] init]; // 創(chuàng)建
for (int i = 0; i < 20000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
[lock lock]; // 加鎖
self.testArray = [NSMutableArray array];
[lock unlock]; // 解鎖
});
}
}
@end
- 進(jìn)入
NSLock番枚，可以看到它遵循NSLocking協(xié)議:
@protocol NSLocking
- (void)lock;
- (void)unlock;
@end
@interface NSLock : NSObject <NSLocking> { ... }
...
@end
@interface NSConditionLock : NSObject <NSLocking> { ... }
...
@end
@interface NSRecursiveLock : NSObject <NSLocking> { ... }
...
@end
@interface NSCondition : NSObject <NSLocking> { ... }
...
@end
NSLocking協(xié)議包含lock和unlock兩個(gè)方法法严。NSLock、NSConditionLock葫笼、NSRecursiveLock深啤、NSCondition都遵循NSLocking協(xié)議
- 現(xiàn)在，我們開(kāi)始尋找
lock源碼的出處:
方法一： 在代碼
[lock lock]加鎖處中路星，加入斷點(diǎn)溯街，打開(kāi)debug匯編模式，一步步執(zhí)行洋丐，查詢?cè)创a的出處： 很遺憾呈昔，發(fā)現(xiàn)找不到方法二：
直接斷點(diǎn)進(jìn)不去，那我們運(yùn)行到斷點(diǎn)處后友绝，加入lock符號(hào)斷點(diǎn)堤尾，再運(yùn)行代碼，發(fā)現(xiàn)找到了迁客，在Foundation庫(kù)中執(zhí)行的:
image.png
可是
Foudation庫(kù)是未開(kāi)源庫(kù)郭宝，我們無(wú)法獲取到源碼坛梁。但是swift是開(kāi)源語(yǔ)言巧勤。我們可以參考swift Foudation庫(kù)。-
打開(kāi)
swift Foundation庫(kù)桃犬，搜索class NSLock:
image.png
我們發(fā)現(xiàn)：
- 1.
init中初始化了pthread_mutex
lock和unlock實(shí)際都是調(diào)用了pthread_mutex相對(duì)于的lock和unlock函數(shù)順便探究
NSRecursiveLock卜范、NSCondition和NSConditionLock：
- 發(fā)現(xiàn)
NSRecursiveLock衔统、NSCodition也是基于pthread_mutex封裝的，但：NSRecursiveLock比NSLock多了一層遞歸邏輯NSCodition比NSLock多了一層pthread_con_init條件鎖海雪。NSConditionLock是在NSCondition的基礎(chǔ)上進(jìn)行的再次封裝缰冤。NSRecursiveLockNSCondition
NSConditionLock
結(jié)論：
鎖必須調(diào)用init方法(new內(nèi)部也調(diào)用了init方法)，因?yàn)?code>init會(huì)完成底層pthread_mutex相關(guān)鎖的初始化
- 所有
遵循NSLocking協(xié)議的鎖類喳魏，底層都是基于pthread_mutex鎖來(lái)實(shí)現(xiàn)的，只是封裝的深度不同怀薛。
NSLock性能接近pthread_mutex刺彩，而pthread_mutex(recursive)、NSRecursiveLock枝恋、NSCondition创倔、NSConditionLock的耗時(shí)一個(gè)比一個(gè)高，就是由對(duì)pthread_mutex的封裝深度決定的焚碌。
2. NSLock畦攘、NSRecursiveLock、@synchronized三者的區(qū)別
我們通過(guò)一個(gè)案例來(lái)進(jìn)行分析和對(duì)比：
案例：
循環(huán)生成多個(gè)全局隊(duì)列的異步線程十电，每個(gè)線程內(nèi)聲明block(testMethod)->實(shí)現(xiàn)block->調(diào)用block->嵌套調(diào)用block（遞歸調(diào)用）要求： 分別使用
NSLock知押、NSRecursiveLock叹螟、@synchronized實(shí)現(xiàn)讀寫安全
- (void)demo{
for (int i= 0; i<10; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
static void (^testMethod)(int);// 1. 聲明
testMethod = ^(int value){ // 2. 實(shí)現(xiàn)Block塊
if (value > 0) {
NSLog(@"current value = %d",value);
testMethod(value - 1); // 4. 嵌套調(diào)用block
}
};
testMethod(10); // 3.調(diào)用block
});
}
}
2.1 使用NSLock:
必須在Block實(shí)現(xiàn)前加鎖，在調(diào)用后解鎖：
相關(guān)實(shí)踐：
調(diào)用前加鎖: 死鎖
image.png
- 僅在
第一次進(jìn)入block時(shí)打印了一次台盯，后面就死鎖了罢绽。
(一直lock加鎖，而沒(méi)有unlock解鎖導(dǎo)致的)2.
調(diào)用后加鎖： 無(wú)效鎖
image.png
- 打印結(jié)果
完全無(wú)序静盅，鎖的作用完全消失
(想想都知道良价，block都執(zhí)行完了，你再上鎖蒿叠，有啥用明垢，鎖了一堆寂寞?? )
- 所以如果使用
NSLock鎖，必須在聲明前加鎖和調(diào)用后解鎖市咽，才能解決數(shù)據(jù)的讀寫安全問(wèn)題痊银。
?? NSLock鎖，只鎖了當(dāng)前線程魂务，當(dāng)我們使用異步多線程操作時(shí)曼验，可能出現(xiàn)線程間相互等待，死鎖的情況
2.2 使用NSRecursiveLock
-
在
聲明前加鎖和調(diào)用后解鎖是正確的粘姜。
image.png -
但由于它具備
遞歸特性鬓照，我們?cè)?code>block內(nèi)部的遞歸前加鎖，當(dāng)前線程也打印正常孤紧，但是其他線程堵塞豺裆。
image.png -
當(dāng)我們?nèi)サ?code>for循環(huán)，僅保持
一個(gè)異步線程号显，在block內(nèi)部的遞歸前后分別加鎖和解鎖臭猜，打印正常：
image.png
這是因?yàn)?code>NSRecursiveLock的遞歸特性。內(nèi)部任務(wù)是遞歸持有的押蚤，所以不會(huì)死鎖蔑歌。
2.3 @synchronized
-
@synchronized最簡(jiǎn)單，直接將block內(nèi)部代碼包裹起來(lái)揽碘，就可以實(shí)現(xiàn)數(shù)據(jù)讀寫安全了
image.png 關(guān)于
@synchronized的內(nèi)部結(jié)構(gòu)次屠，我們上一節(jié)專門分析了。@synchronized能對(duì)記錄被鎖對(duì)象的所有線程雳刺，每個(gè)線程內(nèi)部都是遞歸持有任務(wù)的劫灶。所以在異步多線程中，它既不用擔(dān)心遞歸造成的鎖釋放問(wèn)題掖桦，也不需要關(guān)心線程間的通信問(wèn)題本昏。
NSLock、NSRecursiveLock枪汪、@synchronized三者的區(qū)別
NSLock:
- 需要
手動(dòng)創(chuàng)建和釋放涌穆，需要在準(zhǔn)確的時(shí)機(jī)進(jìn)行相應(yīng)操作怔昨。- 僅鎖住
當(dāng)前線程的當(dāng)前任務(wù)，無(wú)法自動(dòng)實(shí)現(xiàn)線程間的通訊和遞歸問(wèn)題蒲犬。
（上述NSLock代碼實(shí)際上沒(méi)解決遞歸問(wèn)題朱监，只是野蠻的在代碼最外層上了一把大鎖，無(wú)視遞歸內(nèi)部層級(jí)）
NSRecursiveLock:
- 需要
手動(dòng)創(chuàng)建和釋放原叮，需要在準(zhǔn)確的時(shí)機(jī)進(jìn)行相應(yīng)操作赫编。- 僅鎖住
當(dāng)前線程的所有任務(wù)，無(wú)法自動(dòng)實(shí)現(xiàn)線程間的通訊奋隶，但可以解決遞歸問(wèn)題擂送。
（與NSLock不同，NSRecursiveLock是在遞歸時(shí)唯欣，每層加鎖和解鎖嘹吨。對(duì)鎖的控制更為精確）
@synchronized:
- 只需將
需要鎖的代碼都放在作用域內(nèi)，確定被鎖對(duì)象(被鎖對(duì)象決定了鎖的生命周期)境氢，@synchronized就可以做到自動(dòng)創(chuàng)建和釋放蟀拷。
鎖住被鎖對(duì)象的所有線程的所有任務(wù)，可自動(dòng)實(shí)現(xiàn)線程間的通訊萍聊，可以解決遞歸問(wèn)題问芬。
(內(nèi)部邏輯為：被鎖對(duì)象可持有多個(gè)線程，每個(gè)線程可遞歸持有多個(gè)任務(wù))
所以我們日常使用時(shí)寿桨，盡管@synchronized耗時(shí)較大此衅，但是它使用非常簡(jiǎn)單，根本不需要處理各種異常情況亭螟，也不需要手動(dòng)釋放挡鞍。便捷性和安全性都非常好。
3. NSCondition
NSCondition的對(duì)象實(shí)際上是作為一個(gè)鎖和一個(gè)線程檢查器:
-
鎖： 當(dāng)檢查
條件成立時(shí)预烙，保護(hù)數(shù)據(jù)源 -
線程檢查器：
根據(jù)條件判斷是否繼續(xù)運(yùn)行線程（線程是否阻塞）
方法：
[condition lock]：加鎖
（一般用于多線程同時(shí)訪問(wèn)墨微、修改同一個(gè)數(shù)據(jù)源時(shí)，保證同一時(shí)間內(nèi)數(shù)據(jù)源只能被訪問(wèn)扁掸、修改一次欢嘿，其他線程的命令需要在lock外等待，只有unlock后也糊，才可訪問(wèn)）[condition unlock]：解鎖（與lock配對(duì)使用）[condition wait]：讓當(dāng)前線程處于等待狀態(tài)[condition signal]：CPU發(fā)信號(hào)告訴所有線程不用再等待，可以繼續(xù)執(zhí)行羡宙。
- 測(cè)試案例：
有2個(gè)生產(chǎn)者和2個(gè)消費(fèi)者狸剃，各自生產(chǎn)和消費(fèi)各50次。當(dāng)消費(fèi)者購(gòu)買時(shí)狗热，沒(méi)貨就排隊(duì)等待钞馁，有貨就賣貨,一次只能一個(gè)人買虑省， 每當(dāng)生產(chǎn)者生產(chǎn)出一個(gè)貨物時(shí)，都會(huì)廣播告訴所有等待的消費(fèi)者僧凰，進(jìn)行繼續(xù)購(gòu)買探颈。
這樣保障了貨品的數(shù)據(jù)安全（有貨才能賣，一次賣一個(gè)训措，沒(méi)貨就等待）
@interface ViewController ()
@property (nonatomic, assign) NSUInteger ticketCount;
@property (nonatomic, strong) NSCondition *testCondition;
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
self.ticketCount = 0;
[self demo];
}
- (void)demo{
_testCondition = [[NSCondition alloc] init];
//創(chuàng)建生產(chǎn)-消費(fèi)者
for (int i = 0; i < 50; i++) {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
[self producer]; // 生產(chǎn)者
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
[self consumer]; // 消費(fèi)者
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
[self consumer]; // 消費(fèi)者
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
[self producer]; // 生產(chǎn)者
});
}
}
- (void)producer{
[_testCondition lock]; // 操作的多線程影響
self.ticketCount = self.ticketCount + 1;
NSLog(@"生產(chǎn)一個(gè) 現(xiàn)有 count %zd",self.ticketCount);
[_testCondition signal]; // 發(fā)送信號(hào)
[_testCondition unlock];
}
- (void)consumer{
[_testCondition lock]; // 操作的多線程影響
if (self.ticketCount == 0) {
NSLog(@"等待 count %zd",self.ticketCount);
[_testCondition wait]; // 線程等待
}
//注意消費(fèi)行為伪节，要在等待條件判斷之后
self.ticketCount -= 1;
NSLog(@"消費(fèi)一個(gè) 還剩 count %zd ",self.ticketCount);
[_testCondition unlock];
}
@end
-
打印結(jié)果：（生產(chǎn)消費(fèi)數(shù)據(jù)是安全的）
image.png
但是NSCondition使用非常麻煩，需要在合適的地方手動(dòng)加鎖绩鸣、等待怀大、發(fā)送信號(hào)、釋放
于是基于NSCondition呀闻，出現(xiàn)了NSConditionLock鎖
4. NSConditionLock
NSConditionLock是一把鎖化借，一旦一個(gè)線程獲得鎖，其他線程一定等待捡多。
方法：
[xxx lock]：
加鎖
- 如果
沒(méi)有其他線程獲得鎖（不需要判斷內(nèi)部的condition）蓖康，那他能執(zhí)行后續(xù)代碼，同時(shí)設(shè)置當(dāng)前線程獲得鎖垒手。- 如果已經(jīng)
有其他線程獲得鎖（可能是條件鎖蒜焊，或者無(wú)條件鎖），則等待淫奔，直到其他線程解鎖[xxx lockWhenCondition: A條件]：
- 在
[xxx lock]的基礎(chǔ)上山涡，沒(méi)有其他線程獲得鎖，且內(nèi)部的condition條件滿足A條件時(shí)唆迁，才會(huì)執(zhí)行后續(xù)代碼并讓當(dāng)前線程獲得鎖鸭丛。否則依舊是等待[xxx unlockWithCondition: A條件]：
釋放鎖
- 把
內(nèi)部的condition設(shè)置為A條件，并broadcast廣播告訴所有等待的線程唐责。return = [xxx lockWhenCondition: A條件 beforeDate: A時(shí)間]：
沒(méi)有其他線程獲得鎖鳞溉，且滿足A條件，且在A時(shí)間之前鼠哥，可以執(zhí)行后續(xù)代碼并讓當(dāng)前線程獲得鎖熟菲。- 返回值為
NO，表示沒(méi)有改變鎖的狀態(tài)
condition是整數(shù)朴恳，內(nèi)部通過(guò)整數(shù)比較條件
- 通過(guò)下面案例分析：
- (void)demo{
NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
[conditionLock lockWhenCondition:1]; // conditoion = 1 內(nèi)部 Condition 匹配
NSLog(@"線程 1");
[conditionLock unlockWithCondition:0]; // 解鎖并把conditoion設(shè)置為0
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{
[conditionLock lockWhenCondition:2]; // conditoion = 2 內(nèi)部 Condition 匹配
sleep(0.1);
NSLog(@"線程 2");
[conditionLock unlockWithCondition:1]; // 解鎖并把conditoion設(shè)置為1
});
dispatch_async(dispatch_get_global_queue(0, 0), ^{
[conditionLock lock];
NSLog(@"線程 3");
[conditionLock unlock];
});
}
-
打印結(jié)果：
image.png
分析：
- 有三個(gè)
并行隊(duì)列+異步函數(shù)抄罕，分別處理三個(gè)任務(wù)，三個(gè)任務(wù)的執(zhí)行順序無(wú)序于颖。
（并行隊(duì)列+異步線程是的執(zhí)行順序是不固定的呆贿，取決于任務(wù)資源大小和cpu的調(diào)度）- 我們init時(shí)，將condition設(shè)置為2。
- 任務(wù)1： 必須當(dāng)前線程
沒(méi)被鎖做入，且condition為1時(shí)冒晰，我才加鎖并執(zhí)行后面代碼。- 任務(wù)2： 必須當(dāng)前線程
沒(méi)被鎖竟块，且condition為2時(shí)壶运，我才加鎖并執(zhí)行后面代碼。- 任務(wù)3： 必須當(dāng)前線程
沒(méi)被鎖浪秘，我可以加鎖并執(zhí)行后面代碼蒋情。所以
任務(wù)3的執(zhí)行時(shí)期并不確定，只要當(dāng)前線程沒(méi)被鎖秫逝，隨時(shí)都可以恕出。任務(wù)1一定在任務(wù)2的后面：
- 因?yàn)?code>condition初始值為
2，只有任務(wù)2滿足條件违帆，任務(wù)2執(zhí)行完后浙巫，將condition設(shè)置為1，并broadcast廣播給所有等待的線程刷后。- 此時(shí)
正在等待的任務(wù)1的線程收到廣播的畴，檢查任務(wù)1，滿足條件尝胆，任務(wù)1執(zhí)行完后丧裁，將condition設(shè)置為0，并broadcast廣播給所有等待的線程含衔。
-
Swift Foundation源碼中搜索NSConditionLock煎娇，可以看到循環(huán)檢查線程、條件和上鎖過(guò)程:
image.png
感興趣的贪染，我們可以
匯編驗(yàn)證下部分流程：
(匯編是機(jī)器執(zhí)行的代碼缓呛，是最準(zhǔn)確的執(zhí)行順序。找不到源碼時(shí)杭隙，只有它才是最有效的探索路徑)(PS:
匯編確實(shí)很難懂哟绊，這里只是簡(jiǎn)單介紹一下部分流程，主要是思路的拓寬)
- 簡(jiǎn)化測(cè)試代碼：
- (void)demo{ NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2]; dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{ [conditionLock lockWhenCondition:2]; // conditoion = 2 內(nèi)部 Condition 匹配 NSLog(@"線程 2"); [conditionLock unlockWithCondition:1]; // 解鎖并把conditoion設(shè)置為1 }); }
lockWhenCondition加上斷點(diǎn)痰憎，打開(kāi)匯編模式：image.png
image.png
運(yùn)行代碼票髓，執(zhí)行到斷點(diǎn)處，再加入lockWhenCondition:符號(hào)斷點(diǎn)：（注意：冒號(hào)不能少铣耘，前后不能有空格）洽沟，再運(yùn)行代碼：
image.png在
lockWhenCondition:beforeDate:一行加斷點(diǎn)，運(yùn)行至此處蜗细，讀取參數(shù)玲躯，發(fā)現(xiàn)beforeDate的默認(rèn)值是distantFuture：
image.png加入
lockWhenCondition:beforeDate:符號(hào)斷點(diǎn)，運(yùn)行代碼，進(jìn)入到該函數(shù)內(nèi):
image.png發(fā)現(xiàn)首先調(diào)了
lock函數(shù)跷车，我們加入lock斷點(diǎn)，運(yùn)行代碼橱野，發(fā)現(xiàn)內(nèi)部是NSCondition執(zhí)行了lock方法：
image.png回到上一頁(yè)朽缴，我們?cè)?code>pthread_equal下一行加入斷點(diǎn)，運(yùn)行代碼水援。打印相應(yīng)值：
image.png
pthread_equal檢查線程是否存在密强，true：跳到0x7fff207ef545，false：比較r15和rbx偏移0x10位蜗元。
這里實(shí)際就是檢查線程是否存在或渤，如果不存在，再檢查condition是否相等奕扣。才進(jìn)行后續(xù)操作... 大概思路就是這樣... 講個(gè)思路就行薪鹦。 真正的匯編探索，還需要
很大的基本功和海量訓(xùn)練惯豆。
關(guān)于鎖的探索池磁，到此為止。 其他類型的鎖楷兽，可以用類似方式去探索和研究地熄。
