GCD使用經驗與技巧淺談

前言

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

dispatch_once_t必須是全局或static變量

這一條算是「老生常談」了，但我認爲仍是有必要強調一次，畢竟非全局或非static的dispatch_once_t變量在使用時會致使很是很差排查的bug，正確的以下：

1 2 3 4 5

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

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

dispatch_queue_create的第二個參數

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

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

在網上的大部分教程裏（甚至Apple本身的文檔裏），都是這麼建立串行隊列的：

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

看，第二個參數傳的是「NULL」。 可是dispatch_queue_attr_t類型是有已經定義好的常量的，因此我認爲，爲了更加的清晰、嚴謹，最好以下建立隊列：

1 2 3 4

//串行隊列 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是延遲提交，不是延遲運行

先看看官方文檔的說明：

1	Enqueue a block for execution at the specified time.

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

看看以下代碼示例：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

//建立串行隊列 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..."); });

結果以下：

1 2 3

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函數，其原型以下：

1	dispatch_time_t dispatch_time ( dispatch_time_t when, int64_t delta );

第一個參數通常是DISPATCH_TIME_NOW，表示從如今開始。

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

這裏要特別注意的是，delta參數是「納秒！」，就是說，延時1秒的話，delta應該是「1000000000」=。=，太長了，因此理所固然系統提供了常量，以下：

1 2 3

#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，看以下例子：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

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);

運行結果以下：

1 2 3 4 5 6

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任務。可是我我的以爲這個函數就是個「坑」，先看看以下代碼運行結果：

1 2 3 4 5 6 7 8

//建立異步串行隊列 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");

運行的結果是：

1 2 3 4

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時，每每一不當心，就可能形成死鎖，看看下面的「死鎖」例子：

1 2 3 4

//在main線程使用「同步」方法提交Block，一定會死鎖。 dispatch_sync(dispatch_get_main_queue(), ^{     NSLog(@"I am block..."); });

你可能會說，這麼低級的錯誤，我怎麼會犯，那麼，看看下面的：

1 2 3 4 5 6 7 8 9 10 11 12 13

- (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會等循環執行完成，這不就差很少是阻塞了嗎。看以下例子：

1 2 3 4 5 6 7 8 9 10

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函數，簡單有效，簡單例子以下：

1 2 3 4

//省去建立group、queue代碼。。。 dispatch_group_async(group, queue, ^{     //Do you work... });

當你沒法直接使用隊列變量時，就沒法使用dispatch_group_async了，下面以使用AFNetworking時的狀況：

1 2 3 4 5 6 7 8 9 10 11 12 13

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使用，爲隊列設置「析構函數」，在這個函數裏面釋放內存，大體以下：

1 2 3 4 5 6 7 8 9

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