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