前言

GCD(Grand Central Dispatch)可以說是Mac、iOS開發中的一大“利器”，本文就總結一些有關使用GCD的經驗與技巧。

dispatch_once_t必須是全局或static變量

這一條算是“老生常談”了，但我認為還是有必要強調一次，畢竟非全局或非static的dispatch_once_t變量在使用時會導致非常不好排查的bug，正確的如下：

//靜態變量，保證只有一份實例，才能確保只執行一次
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
   //單例代碼 
});

其實就是保證dispatch_once_t只有一份實例。

dispatch_queue_create的第二個參數

dispatch_queue_create，創建隊列用的，它的參數只有兩個，原型如下：

dispatch_queue_t dispatch_queue_create ( const char *label, dispatch_queue_attr_t attr );

在網上的大部分教程裡（甚至Apple自己的文檔裡），都是這麼創建串行隊列的：

dispatch_queue_t queue = dispatch_queue_create("com.example.MyQueue", NULL);

看，第二個參數傳的是“NULL”。 但是dispatch_queue_attr_t類型是有已經定義好的常量的，所以我認為，為了更加的清晰、嚴謹，最好如下創建隊列：

//串行隊列
dispatch_queue_t queue = dispatch_queue_create("com.example.MyQueue", DISPATCH_QUEUE_SERIAL);
//並行隊列
dispatch_queue_t queue = dispatch_queue_create("com.example.MyQueue", DISPATCH_QUEUE_CONCURRENT);

常量就是為了使代碼更加“易懂”，更加清晰，既然有，為啥不用呢~

dispatch_after是延遲提交，不是延遲運行

先看看官方文檔的說明：

Enqueue a block for execution at the specified time.

Enqueue，就是入隊，指的就是將一個Block在特定的延時以後，加入到指定的隊列中，不是在特定的時間後立即運行！。

看看如下代碼示例：

//創建串行隊列
dispatch_queue_t queue = dispatch_queue_create("me.tutuge.test.gcd", DISPATCH_QUEUE_CONCURRENT);
//立即打印一條信息        
NSLog(@"Begin add block...");        
//提交一個block
dispatch_async(queue, ^{
    //Sleep 10秒
    [NSThread sleepForTimeInterval:10];
    NSLog(@"First block done...");
});        
//5 秒以後提交block
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), queue, ^{
    NSLog(@"After...");
});

結果如下：

2015-03-31 20:57:27.122 GCDTest[45633:1812016] Begin add block...
2015-03-31 20:57:37.127 GCDTest[45633:1812041] First block done...
2015-03-31 20:57:37.127 GCDTest[45633:1812041] After...

從結果也驗證了，dispatch_after只是延時提交block，並不是延時後立即執行。所以想用dispatch_after精確控制運行狀態的朋友可要注意了~

正確創建dispatch_time_t

用dispatch_after的時候就會用到dispatch_time_t變量，但是如何創建合適的時間呢？答案就是用dispatch_time函數，其原型如下：

dispatch_time_t dispatch_time ( dispatch_time_t when, int64_t delta );

第一個參數一般是DISPATCH_TIME_NOW，表示從現在開始。

那麼第二個參數就是真正的延時的具體時間。

這裡要特別注意的是，delta參數是“納秒！”，就是說，延時1秒的話，delta應該是“1000000000”=。=，太長了，所以理所當然系統提供了常量，如下：

#define NSEC_PER_SEC 1000000000ull
#define USEC_PER_SEC 1000000ull
#define NSEC_PER_USEC 1000ull

關鍵詞解釋：

• NSEC：納秒。

• USEC：微妙。

• SEC：秒

• PER：每

所以：

1. NSEC_PER_SEC，每秒有多少納秒。

2. USEC_PER_SEC，每秒有多少毫秒。（注意是指在納秒的基礎上）

3. 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的使用分如下幾步：

1. 創建dispatch_group_t

2. 添加任務（block）

3. 添加結束任務（如清理操作、通知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就可以方便的將一系列網絡請求“打包”起來~

添加結束任務

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

1. 在當前線程阻塞的同步等待：dispatch_group_wait。

2. 添加一個異步執行的任務作為結束任務：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