GCD使用經驗與技巧淺談

1、單例：

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

2、建立佇列

//序列佇列
dispatch_queue_t queue = dispatch_queue_create("com.example.MyQueue", NULL);
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);

3、dispatch_after是延遲提交，而不是延遲執行，用來精確控制執行狀態是錯誤的。

4、死鎖的避免，沒什麼事別用dispatch_sync！

//在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];
        //  死鎖分析：此處Block會在dispatch_get_main_queue()中執行而updateUI2方法中有一個
        //            "在main執行緒使用“同步”方法提交Block"
        //  --> 必定死鎖
    });
}
- (void)updateUI2 {
    dispatch_sync(dispatch_get_main_queue(), ^{
        NSLog(@"Update ui 2");
    });
}

5、分步驟完成並行任務：dispatch_group

1. 建立dispatch_group_t

2. 新增任務（block）

3. 新增結束任務（如清理操作、通知UI等）

6、dispatch_barrier_(a)sync：等正在執行的block執行完畢之後攜帶的這個Block搶佔執行，執行完畢後繼續執行後面的。（只在自己建立的併發佇列上有效，其他等同dispatch_(a)sync）

http://tutuge.me/2015/04/03/something-about-gcd/

前言

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

  
  

• 建立dispatch_group_t

• 新增任務（block）

• 新增結束任務（如清理操作、通知UI等）