在這篇文章中，我將為你整理一下 iOS 開發中幾種多執行緒方案，以及其使用方法和注意事項。當然也會給出幾種多執行緒的案例，在實際使用中感受它們的區別。還有一點需要說明的是，這篇文章將會使用 Swift 和 Objective-c 兩種語言講解，雙語幼兒園。OK，let’s begin!

概述
這篇文章中，我不會說多執行緒是什麼、執行緒和程序的區別、多執行緒有什麼用，當然我也不會說什麼是序列、什麼是並行等問題，這些我們應該都知道的。

在 iOS 中其實目前有 4 套多執行緒方案，他們分別是：

Pthreads
NSThread
GCD
NSOperation & NSOperationQueue
所以接下來，我會一一講解這些方案的使用方法和一些案例。在將這些內容的時候，我也會順帶說一些多執行緒周邊產品。比如： 執行緒同步、 延時執行、 單例模式 等等。

Pthreads
其實這個方案不用說的，只是拿來充個數，為了讓大家瞭解一下就好了。百度百科裡是這麼說的：

POSIX執行緒（POSIX threads），簡稱Pthreads，是執行緒的POSIX標準。該標準定義了建立和操縱執行緒的一整套API。在類Unix作業系統（Unix、Linux、Mac OS X等）中，都使用Pthreads作為作業系統的執行緒。
簡單地說，這是一套在很多作業系統上都通用的多執行緒API，所以移植性很強（然並卵），當然在 iOS 中也是可以的。不過這是基於 c語言 的框架，使用起來這酸爽！感受一下：

OBJECTIVE-C
當然第一步要包含標頭檔案

import

define NSEC_PER_SEC 1000000000ull

define USEC_PER_SEC 1000000ull

define NSEC_PER_USEC 1000ull

關鍵詞解釋：

NSEC：納秒。
USEC：微妙。
SEC：秒
PER：每
所以：

NSEC_PER_SEC，每秒有多少納秒。
USEC_PER_SEC，每秒有多少毫秒。（注意是指在納秒的基礎上）
NSEC_PER_USEC，每毫秒有多少納秒。
所以，延時1秒可以寫成如下幾種：

dispatch_time(DISPATCH_TIME_NOW, 1 * NSEC_PER_SEC);
dispatch_time(DISPATCH_TIME_NOW, 1000 * USEC_PER_SEC);
dispatch_time(DISPATCH_TIME_NOW, USEC_PER_SEC * NSEC_PER_USEC);
最後一個“USEC_PER_SEC * NSEC_PER_USEC”，翻譯過來就是“每秒的毫秒數乘以每毫秒的納秒數”，也就是“每秒的納秒數”，所以，延時500毫秒之類的，也就不難了吧~

dispatch_suspend != 立即停止佇列的執行

dispatch_suspend，dispatch_resume提供了“掛起、恢復”佇列的功能，簡單來說，就是可以暫停、恢復佇列上的任務。但是這裡的“掛起”，並不能保證可以立即停止佇列上正在執行的block，看如下例子：

dispatch_queue_t queue = dispatch_queue_create(“me.tutuge.test.gcd”, DISPATCH_QUEUE_SERIAL);

//提交第一個block，延時5秒列印。
dispatch_async(queue, ^{
[NSThread sleepForTimeInterval:5];
NSLog(@”After 5 seconds…”);
});

//提交第二個block，也是延時5秒列印
dispatch_async(queue, ^{
[NSThread sleepForTimeInterval:5];
NSLog(@”After 5 seconds again…”);
});

//延時一秒
NSLog(@”sleep 1 second…”);
[NSThread sleepForTimeInterval:1];

//掛起佇列
NSLog(@”suspend…”);
dispatch_suspend(queue);

//延時10秒
NSLog(@”sleep 10 second…”);
[NSThread sleepForTimeInterval:10];

//恢復佇列
NSLog(@”resume…”);
dispatch_resume(queue);
執行結果如下：

2015-04-01 00:32:09.903 GCDTest[47201:1883834] sleep 1 second…
2015-04-01 00:32:10.910 GCDTest[47201:1883834] suspend…
2015-04-01 00:32:10.910 GCDTest[47201:1883834] sleep 10 second…
2015-04-01 00:32:14.908 GCDTest[47201:1883856] After 5 seconds…
2015-04-01 00:32:20.911 GCDTest[47201:1883834] resume…
2015-04-01 00:32:25.912 GCDTest[47201:1883856] After 5 seconds again…
可知，在dispatch_suspend掛起佇列後，第一個block還是在執行，並且正常輸出。
結合文件，我們可以得知，dispatch_suspend並不會立即暫停正在執行的block，而是在當前block執行完成後，暫停後續的block執行。

所以下次想暫停正在佇列上執行的block時，還是不要用dispatch_suspend了吧~

“同步”的dispatch_apply

dispatch_apply的作用是在一個佇列（序列或並行）上“執行”多次block，其實就是簡化了用迴圈去向佇列依次新增block任務。但是我個人覺得這個函式就是個“坑”，先看看如下程式碼執行結果：

//建立非同步序列佇列
dispatch_queue_t queue = dispatch_queue_create(“me.tutuge.test.gcd”, DISPATCH_QUEUE_SERIAL);

//執行block3次
dispatch_apply(3, queue, ^(size_t i) {
NSLog(@”apply loop: %zu”, i);
});

//列印資訊
NSLog(@”After apply”);
執行的結果是：

2015-04-01 00:55:40.854 GCDTest[47402:1893289] apply loop: 0
2015-04-01 00:55:40.856 GCDTest[47402:1893289] apply loop: 1
2015-04-01 00:55:40.856 GCDTest[47402:1893289] apply loop: 2
2015-04-01 00:55:40.856 GCDTest[47402:1893289] After apply
看，明明是提交到非同步的佇列去執行，但是“After apply”居然在apply後列印，也就是說，dispatch_apply將外面的執行緒（main執行緒）“阻塞”了！

檢視官方文件，dispatch_apply確實會“等待”其所有的迴圈執行完畢才往下執行=。=，看來要小心使用了。

避免死鎖！

dispatch_sync導致的死鎖

涉及到多執行緒的時候，不可避免的就會有“死鎖”這個問題，在使用GCD時，往往一不小心，就可能造成死鎖，看看下面的“死鎖”例子：

//在main執行緒使用“同步”方法提交Block，必定會死鎖。
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@”I am block…”);
});
你可能會說，這麼低階的錯誤，我怎麼會犯，那麼，看看下面的：

• (void)updateUI1 {
  dispatch_sync(dispatch_get_main_queue(), ^{
  NSLog(@”Update ui 1”);

  //死鎖！
  [self updateUI2];
  

  });
  }

• (void)updateUI2 {
  dispatch_sync(dispatch_get_main_queue(), ^{
  NSLog(@”Update ui 2”);
  });
  }
  在你不注意的時候，巢狀呼叫可能就會造成死鎖！所以為了“世界和平”=。=，我們還是少用dispatch_sync吧。

dispatch_apply導致的死鎖！

啥，dispatch_apply導致的死鎖？。。。是的，前一節講到，dispatch_apply會等迴圈執行完成，這不就差不多是阻塞了嗎。看如下例子：

dispatch_queue_t queue = dispatch_queue_create(“me.tutuge.test.gcd”, DISPATCH_QUEUE_SERIAL);

dispatch_apply(3, queue, ^(size_t i) {
NSLog(@”apply loop: %zu”, i);

//再來一個dispatch_apply！死鎖！      
dispatch_apply(3, queue, ^(size_t j) {
    NSLog(@"apply loop inside %zu", j);
});

});
這端程式碼只會輸出“apply loop: 1”。。。就沒有然後了=。=

所以，一定要避免dispatch_apply的巢狀呼叫。

靈活使用dispatch_group

很多時候我們需要等待一系列任務（block）執行完成，然後再做一些收尾的工作。如果是有序的任務，可以分步驟完成的，直接使用序列佇列就行。但是如果是一系列並行執行的任務呢？這個時候，就需要dispatch_group幫忙了~總的來說，dispatch_group的使用分如下幾步：

建立dispatch_group_t
新增任務（block）
新增結束任務（如清理操作、通知UI等）
下面著重講講在後面兩步。

新增任務

新增任務可以分為以下兩種情況：

自己建立佇列：使用dispatch_group_async。
無法直接使用佇列變數（如使用AFNetworking新增非同步任務）：使用dispatch_group_enter，dispatch_group_leave。
自己建立佇列時，當然就用dispatch_group_async函式，簡單有效，簡單例子如下：

//省去建立group、queue程式碼。。。

dispatch_group_async(group, queue, ^{
//Do you work…
});
當你無法直接使用佇列變數時，就無法使用dispatch_group_async了，下面以使用AFNetworking時的情況：

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];

//Enter group
dispatch_group_enter(group);
[manager GET:@”http://www.baidu.com” parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {
//Deal with result…

//Leave group
dispatch_group_leave(group);

} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
//Deal with error…

//Leave group
dispatch_group_leave(group);

}];

//More request…
使用dispatch_group_enter，dispatch_group_leave就可以方便的將一系列網路請求“打包”起來~

新增結束任務

新增結束任務也可以分為兩種情況，如下：

在當前執行緒阻塞的同步等待：dispatch_group_wait。
新增一個非同步執行的任務作為結束任務：dispatch_group_notify
這兩個比較簡單，就不再貼程式碼了=。=

使用dispatch_barrier_async,dispatch_barrier_sync的注意事項

dispatch_barrier_async的作用就是向某個佇列插入一個block，當目前正在執行的block執行完成後，阻塞這個block後面新增的block，只執行這個block直到完成，然後再繼續後續的任務，有點“唯我獨尊”的感覺=。=

值得注意的是：

dispatchbarrier(a)sync只在自己建立的併發佇列上有效，在全域性(Global)併發佇列、序列佇列上，效果跟dispatch_(a)sync效果一樣。
既然在序列佇列上跟dispatch_(a)sync效果一樣，那就要小心別死鎖！
dispatch_set_context與dispatch_set_finalizer_f的配合使用

dispatch_set_context可以為佇列新增上下文資料，但是因為GCD是C語言介面形式的，所以其context引數型別是“void *”。也就是說，我們建立context時有如下幾種選擇：

用C語言的malloc建立context資料。
用C++的new建立類物件。
用Objective-C的物件，但是要用__bridge等關鍵字轉為Core Foundation物件。
以上所有建立context的方法都有一個必須的要求，就是都要釋放記憶體！，無論是用free、delete還是CF的CFRelease，我們都要確保在佇列不用的時候，釋放context的記憶體，否則就會造成記憶體洩露。

所以，使用dispatch_set_context的時候，最好結合dispatch_set_finalizer_f使用，為佇列設定“解構函式”，在這個函式裡面釋放記憶體，大致如下：

void cleanStaff(void *context) {
//釋放context的記憶體！

//CFRelease(context);
//free(context);
//delete context;

}

…

//在佇列建立後，設定其“解構函式”
dispatch_set_finalizer_f(queue, cleanStaff);
詳細用法，請看我之前寫的Blog為GCD佇列繫結NSObject型別上下文資料-利用__bridge_retained(transfer)轉移記憶體管理權

總結

其實本文更像是總結了GCD中的“坑”=。=

至於經驗，總結一條，就是使用任何技術，都要研究透徹，否則後患無窮啊~

參考

Grand Central Dispatch (GCD) Reference
Concurrency Programming Guide
Using Dispatch Groups to Wait for Multiple Web Services