学习多线程,转载两篇大神的帖子,留着以后回顾!
第一篇:关于iOS多线程,你看我就够了 http://www.jianshu.com/p/0b0d9b1f1f19
第二篇:GCD使用经验与技巧浅谈 http://tutuge.me/2015/04/03/something-about-gcd/index.html
都很不错,还有很多关联文章,慢慢学!!!多看原帖!!!
在这篇文章中,我将为你整理一下 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