你不知道的的 iOS 多線程

程序員用有限的生命去追求無限的知識。

有言在先

首先我不是故意要做標題黨的，也不是我要炒冷飯，我只是想換個姿勢看多線程，本文大部分內容在分析如何造死鎖，奈何功力尚淺，然而再淺，也需要走出第一步。打開你的 Xcode 來驗證這些死鎖吧。

多線程小知識

以下是實現多線程的三種方式：

• NSThread
• GCD
• NSOperationQueue

關于具體使用的方法不再具體介紹，讓我們來看看他們不為人知的一面

1. 鎖的背后

NSLock是基于 POSIX threads 實現的，而 POSIX threads 中使用互斥量同步線程。

互斥量（或稱為互斥鎖）是 pthread 庫為解決這個問題提供的一個基本的機制。互斥量是一個鎖，它保證如下三件事情：

• 原子性 - 鎖住一個互斥量是一個原子操作，表明操作系統保證如果在你已經鎖了一個互斥量，那么在同一時刻就不會有其他線程能夠鎖住這個互斥量；
• 奇異性 - 如果一個線程鎖住了一個互斥量，那么可以保證的是在該線程釋放這個鎖之前沒有其他線程可以鎖住這個互斥量；
• 非忙等待 - 如果一個線程（線程1）嘗試去鎖住一個由線程2鎖住的鎖，線程1會掛起（suspend）并且不會消耗任何CPU資源，直到線程2釋放了這個鎖。這時，線程1會喚醒并繼續執行，鎖住這個互斥量。

2. 關于生命周期

通過 [NSThread exit] 方法使線程退出 ，NSThread 是可以立即終止正在執行的任務（可能會造成內存泄露，這里不深究）。甚至你可以在主線程中執行該操作，會使主線程也退出，app 無法再響應事件。而 cancel 可以通過作為標志位來達到類似目的，如果不做任何處理，仍然會繼續執行。

GCD和NSOperationQueue可以取消隊列中未開始執行的任務，對于已經開始執行的任務就無能為力了。

3. 并行與并發

看到很多「看我就夠了」系列文章里提到 并發隊列 ，這里有一個小陷阱，混淆了 并發 和 并行 的概念。我們先來看看一下他們之間的區別：

并發與并行

從圖中可以看到，并行才是真正的多線程，而并發只是在多任務中切換。一般多核CPU可以并行執行多個線程，而單核CPU實際上只有一個線程，多路復用達到接近同時執行的效果。在 iOS 中 concurrentQueue 和 globalQueue 從 Xcode 中線程使用情況來看，都達到了并行的效果，雖然名字是并發。

4. 隊列與線程

隊列是保存以及管理任務的，將任務加到隊列中，任務會按照加入到隊列中先后順序依次執行。如果是全局隊列和并行隊列，則系統會根據系統資源去創建新的線程去處理隊列中的任務，線程的創建、維護和銷毀由操作系統管理，還有隊列本身是線程安全的。

使用 NSOperationQueue 實現多線程的時候是可以控制線程總數及線程依賴關系的，而 GCD 只能選擇并行或者串行隊列。

資源競爭

多線程同時執行任務能提高程序的執行效率和響應時間，但是多線程不可避免地遇到同時操作同一資源的情況。前段時間看到的一個資源競爭的問題為例：

@property (nonatomic, strong) NSString *target; dispatch_queue_t queue = dispatch_queue_create("parallel", DISPATCH_QUEUE_CONCURRENT); for (int i = 0; i < 1000000 ; i++) { dispatch_async(queue, ^{ self.target = [NSString stringWithFormat:@"ksddkjalkjd%d",i]; }); }

解決辦法：

• @property (nonatomic, strong) NSString *target;將nonatomic改成atomic。
• 將并行隊列 DISPATCH_QUEUE_CONCURRENT 改成串行隊列 DISPATCH_QUEUE_SERIAL。
• 異步執行dispatch_async 改成同步執行dispatch_sync。
• 賦值使用@synchronized 或者上鎖。

這些方法都是從避免同時訪問的角度來解決該問題，有更好的方法歡迎分享。

花樣死鎖

任何事情都有兩面性，就像多線程能提升效率的同時，也會造成資源競爭的問題。而鎖在保證多線程的數據安全的同時，粗心大意之下也容易發生問題，那就是 死鎖 。

1. NSOperationQueue

鑒于 NSOperationQueue 高度封裝，使用起來非常簡單，一般不會出什么幺蛾子，下面的案例展示了一個不好示范，通常我們通過控制 NSOperation 之間的從屬關系，來達到有序執行任務的效果，但是如果互相從屬或者循環從屬都會造成所有任務無法開始。

NSBlockOperation *blockOperation1 = [NSBlockOperation blockOperationWithBlock:^{ NSLog(@"lock 1 start"); [NSThread sleepForTimeInterval:1]; NSLog(@"lock 1 over"); }]; NSBlockOperation *blockOperation2 = [NSBlockOperation blockOperationWithBlock:^{ NSLog(@"lock 2 start"); [NSThread sleepForTimeInterval:1]; NSLog(@"lock 2 over"); }]; NSBlockOperation *blockOperation3 = [NSBlockOperation blockOperationWithBlock:^{ NSLog(@"lock 3 start"); [NSThread sleepForTimeInterval:1]; NSLog(@"lock 3 over"); }]; // 循環從屬 [blockOperation2 addDependency:blockOperation1]; [blockOperation3 addDependency:blockOperation2]; [blockOperation1 addDependency:blockOperation3]; // 循環的罪魁禍首 // 互相從屬 //[blockOperation1 addDependency:blockOperation2]; //[blockOperation2 addDependency:blockOperation1]; [_operationQueue addOperation:blockOperation1]; [_operationQueue addOperation:blockOperation2]; [_operationQueue addOperation:blockOperation3];

有沒有人試過下面這種情況，如果好奇就試試吧！

[blockOperation1 addDependency:blockOperation1];

2. GCD

大多數開發者都知道在主線程里同步執行任務會造成死鎖，一起來看看還有哪些情況下會造成死鎖或類似問題。

a. 在主線程同步執行 造成 EXC_BAD_INSTRUCEION 錯誤:

- (void)deadlock1 { dispatch_sync(dispatch_get_main_queue(), ^{ NSLog(@"task 1 start"); [NSThread sleepForTimeInterval:1.0]; NSLog(@"task 1 over"); }); }

b. 和主線程同步執行類似，在串行隊列中嵌套使用同步執行任務，同步隊列 task1 執行完成后才能執行 task2 ，而 task1 中嵌套了task2 導致 task1 注定無法完成。

- (void)deadlock2 { dispatch_queue_t queue = dispatch_queue_create("com.xietao3.sync", DISPATCH_QUEUE_SERIAL); dispatch_sync(queue, ^{ // 此處異步同樣會造成互相等待 NSLog(@"task 1 start"); dispatch_sync(queue, ^{ NSLog(@"task 2 start"); [NSThread sleepForTimeInterval:1.0]; NSLog(@"task 2 over"); }); NSLog(@"task 1 over"); }); }

嵌套同步執行任務確實很容易出 bug ，但不是絕對，將同步隊列DISPATCH_QUEUE_SERIAL 換成并行隊列 DISPATCH_QUEUE_CONCURRENT 這個問題就迎刃而解。修改成并行隊列后案例中 task1 仍然要先執行完嵌套在其中的 task2 ，而 task2 開始執行時，隊列會另起一個線程執行 task2 ， task2 執行完成后 task1 繼續執行。

c. 在很多人印象中，異步執行不容易發生互相等待的情況，確實，即使是串行隊列，異步任務會等待當前任務執行后再開始，除非你加了一些不健康的佐料。

- (void)deadlock3 { dispatch_queue_t queue = dispatch_queue_create("com.xietao3.asyn", DISPATCH_QUEUE_SERIAL); dispatch_semaphore_t semaphore = dispatch_semaphore_create(0); dispatch_async(queue, ^{ __block NSString *str = @"xietao3"; // 線程1 創建數據 dispatch_async(queue, ^{ str = [NSString stringWithFormat:@"%ld",[str hash]]; // 線程2 加工數據 dispatch_semaphore_signal(semaphore); }); dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER); NSLog(@"%@",str); // 線程1 使用加工后的數據 }); }

d. 常規死鎖，在已經上鎖的情況下再次上鎖，形成彼此等待的局面。

if (!_lock) _lock = [NSLock new]; dispatch_queue_t queue = dispatch_queue_create("com.xietao3.sync", DISPATCH_QUEUE_CONCURRENT); [_lock lock]; dispatch_sync(queue, ^{ [_lock lock]; [NSThread sleepForTimeInterval:1.0]; [_lock unlock]; }); [_lock unlock];

要解決也比較簡單，將NSLock換成遞歸鎖NSRecursiveLock，遞歸鎖就像普通的門鎖，順時針轉一圈加鎖后，逆時針一圈即解鎖；而如果順時針兩圈，同樣逆時針兩圈即可解鎖。下面來一個遞歸的例子：

// 以下代碼可以理解為順時針轉10圈上鎖，逆時針轉10圈解鎖

- (void)recursivelock:(int)count { if (count>10) return; count++; if (!_recursiveLock) _recursiveLock = [NSRecursiveLock new]; [_recursiveLock lock]; NSLog(@"task%d start",count); [self recursivelock:count]; NSLog(@"task%d over",count); [_recursiveLock unlock]; }

3. 其他

除了上面提到的互斥鎖和遞歸鎖，其他的鎖還有：

• OSSpinLock(自旋鎖)
• pthread_mutex（OC中鎖的底層實現）
• NSConditionLock（條件鎖，對于新手更容易產生死鎖）
• NSCondition（條件鎖的底層實現）
• @synchronized（對象鎖）

大部分鎖觸發死鎖的情況和互斥鎖基本一致，NSConditionLock使用起來會更加靈活，而自旋鎖雖然性能爆表，但是存在漏洞，希望了解更多關于鎖的知識可以點這里，在看的同時不要忘記親自動手驗證一下，邊看邊寫邊驗證，記得更加深刻。

總結

關于多線程、鎖的文章已經爛大街了，本文盡可能地從新的角度來看問題，盡量不寫那些重復的內容，希望對你有所幫助，如果文中內容有誤，歡迎指出。

推薦

2020大廠面試題

關于Flutter的面試題

20道經典面試題

點擊進群密碼:111 更多面試資料等你來拿 更多技術等你來探討

總結

以上是生活随笔為你收集整理的多线程 循环 锁_大多数人还不清楚的iOS多线程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。