iOS多线程到底不安全在哪里？
招聘信息：
iOS多线程安全的概念在很多地方都会遇到，为什么不安全，不安全又该怎么去定义，其实是个值得深究的话题。共享状态，多线程共同访问某个对象的property，在iOS编程里是很普遍的使用场景，我们就从Property的多线程安全说起。Property当我们讨论property多线程安全的时候，很多人都知道给property加上atomic attribute之后，可以一定程度的保障多线程安全，类似：@property&(atomic,&strong)&NSString*&&&&&&&&&&&&&&&&&userN事情并没有看上去这么简单，要分析property在多线程场景下的表现，需要先对property的类型做区分。我们可以简单的将property分为值类型和对象类型，值类型是指primitive type，包括int, long, bool等非对象类型，另一种是对象类型，声明为指针，可以指向某个符合类型定义的内存区域。上述代码中userName明显是个对象类型，当我们访问userName的时候，访问的有可能是userName本身，也有可能是userName所指向的内存区域。比如：self.userName&=&@"peak";是在对指针本身进行赋值。而[self.userName&rangeOfString:@"peak"];是在访问指针指向的字符串所在的内存区域，这二者并不一样。所以我们可以大致上将property分为三类：分完类之后，我们需要明白这三类property的内存模型。Memory Layout当我们讨论多线程安全的时候，其实是在讨论多个线程同时访问一个内存区域的安全问题。针对同一块区域，我们有两种操作，读（load）和写（store），读和写同时发生在同一块区域的时候，就有可能出现多线程不安全。所以展开讨论之前，先要明白上述三种property的内存模型，可用如下图示：以64位系统为例，指针NSString*是8个字节的内存区域，int count是个4字节的区域，而@“Peak”是一块根据字符串长度而定的内存区域。当我们访问property的时候，实际上是访问上图中三块内存区域。self.userName&=&@"peak";是修改第一块区域。self.count&=&10;是在修改第二块区域。[self.userName&rangeOfString:@"peak"];是在读取第三块区域。不安全的定义明白了property的类型以及他们对应的内存模型，我们再来看看不安全的定义。Wikipedia如是说：&A piece of code is&thread-safe&if it manipulates shared data structures only in a manner that guarantees safe execution by multiple threads at the same time这段定义看起来还是有点抽象，我们可以将多线程不安全解释为：多线程访问时出现意料之外的结果。这个意料之外的结果包含几种场景，不一定是指crash，后面再一一分析。先来看下多线程是如何同时访问内存的。不考虑CPU cache对变量的缓存，内存访问可以用下图表示：从上图中可以看出，我们只有一个地址总线，一个内存。即使是在多线程的环境下，也不可能存在两个线程同时访问同一块内存区域的场景，内存的访问一定是通过一个地址总线串行排队访问的，所以在继续后续之前，我们先要明确几个结论：结论一：内存的访问时串行的，并不会导致内存数据的错乱或者应用的crash。结论二：如果读写（load or store）的内存长度小于等于地址总线的长度，那么读写的操作是原子的，一次完成。比如bool，int，long在64位系统下的单次读写都是原子操作。接下来我们根据上面三种property的分类逐一看下多线程的不安全场景。值类型Property先以BOOL值类型为例，当我们有两个线程访问如下property的时候：@property&(nonatomic,&assgin)&BOOL&&&&isD
//thread&1
bool&isDeleted&=&self.isD
//thread&2
self.isDeleted&=&线程1和线程2，一个读(load)，一个写(store)，对于BOOL isDeleted的访问可能有先后之分，但一定是串行排队的。而且由于BOOL大小只有1个字节，64位系统的地址总线对于读写指令可以支持8个字节的长度，所以对于BOOL的读和写操作我们可以认为是原子的，所以当我们声明BOOL类型的property的时候，从原子性的角度看，使用atomic和nonatomic并没有实际上的区别（当然如果重载了getter方法就另当别论了）。如果是int类型呢？@property&(nonatomic,&assgin)&int&&&&
//thread&1
int&curCount&=&self.
//thread&2
self.count&=&1;同理int类型长度为4字节，读和写都可以通过一个指令完成，所以理论上读和写操作都是原子的。从访问内存的角度看nonatomic和atomic也并没有什么区别。atomic到底有什么用呢？据我所知，用处有二：用处一：&生成原子操作的getter和setter。设置atomic之后，默认生成的getter和setter方法执行是原子的。也就是说，当我们在线程1执行getter方法的时候（创建调用栈，返回地址，出栈），线程B如果想执行setter方法，必须先等getter方法完成才能执行。举个例子，在32位系统里，如果通过getter返回64位的double，地址总线宽度为32位，从内存当中读取double的时候无法通过原子操作完成，如果不通过atomic加锁，有可能会在读取的中途在其他线程发生setter操作，从而出现异常值。如果出现这种异常值，就发生了多线程不安全。用处二：设置Memory Barrier对于Objective C的实现来说，几乎所有的加锁操作最后都会设置memory barrier，atomic本质上是对getter，setter加了锁，所以也会设置memory barrier。官方文档表述如下：Note:&Most types of locks also incorporate a memory barrier to ensure that any preceding load and store instructions are completed before entering the critical section.memory barrier有什么用处呢？memory barrier能够保证内存操作的顺序，按照我们代码的书写顺序来。听起来有点不可思议，事实是编译器会对我们的代码做优化，在它认为合理的场景改变我们代码最终翻译成的机器指令顺序。也就是说如下代码：self.intA&=&0;&&//line&1
self.intB&=&1;&//line&2编译器可能在一些场景下先执行line2，再执行line1，因为它认为A和B之间并不存在依赖关系，虽然在代码执行的时候，在另一个线程intA和intB存在某种依赖，必须要求line1先于line2执行。如果设置property为atomic，也就是设置了memory barrier之后，就能够保证line1的执行一定是先于line2的，当然这种场景非常罕见，一则是出现变量跨线程访问依赖，二是遇上编译器的优化，两个条件缺一不可。这种极端的场景下，atomic确实可以让我们的代码更加多线程安全一点，但我写iOS代码至今，还未遇到过这种场景，较大的可能性是编译器已经足够聪明，在我们需要的地方设置memory barrier了。是不是使用了atomic就一定多线程安全呢？我们可以看看如下代码：@property&(atomic,&assign)&&&&int&&&&&&&intA;
//thread&A
for&(int&i&=&0;&i&<&10000;&i&++)&{
&&&&self.intA&=&self.intA&+&1;
&&&&NSLog(@"Thread&A:&%d\n",&self.intA);
//thread&B
for&(int&i&=&0;&i&<&10000;&i&++)&{
&&&&self.intA&=&self.intA&+&1;
&&&&NSLog(@"Thread&B:&%d\n",&self.intA);
}即使我将intA声明为atomic，最后的结果也不一定会是20000。原因就是因为self.intA = self.intA + 1;不是原子操作，虽然intA的getter和setter是原子操作，但当我们使用intA的时候，整个语句并不是原子的，这行赋值的代码至少包含读取(load)，+1(add)，赋值(store)三步操作，当前线程store的时候可能其他线程已经执行了若干次store了，导致最后的值小于预期值。这种场景我们也可以称之为多线程不安全。指针Property指针Property一般指向一个对象，比如：@property&(atomic,&strong)&NSString*&&&&&&&&&&&&&&&&&userN无论iOS系统是32位系统还是64位，一个指针的值都能通过一个指令完成load或者store。但和primitive type不同的是，对象类型还有内存管理的相关操作。在MRC时代，系统默认生成的setter类似如下：-&(void)setUserName:(NSString&*)userName&{
&&&&if(_uesrName&!=&userName)&{
&&&&&&&&[userName&retain];
&&&&&&&&[_userName&release];
&&&&&&&&_userName&=&userN
}不仅仅是赋值操作，还会有retain，release调用。如果property为nonatomic，上述的setter方法就不是原子操作，我们可以假设一种场景，线程1先通过getter获取当前_userName，之后线程2通过setter调用[_userName release];，线程1所持有的_userName就变成无效的地址空间了，如果再给这个地址空间发消息就会导致crash，出现多线程不安全的场景。到了ARC时代，Xcode已经替我们处理了retain和release，绝大部分时候我们都不需要去关心内存的管理，但retain，release其实还是存在于最后运行的代码当中，atomic和nonatomic对于对象类的property声明理论上还是存在差异，不过我在实际使用当中，将NSString*设置为nonatomic也从未遇到过上述多线程不安全的场景，极有可能ARC在内存管理上的优化已经将上述场景处理过了，所以我个人觉得，如果只是对对象类property做read，write，atomic和nonatomic在多线程安全上并没有实际差别。指针Property指向的内存区域这一类多线程的访问场景是我们很容易出错的地方，即使我们声明property为atomic，依然会出错。因为我们访问的不是property的指针区域，而是property所指向的内存区域。可以看如下代码：@property&(atomic,&strong)&NSString*&&&&&&&&&&&&&&&&&stringA;
//thread&A
for&(int&i&=&0;&i&<&100000;&i&++)&{
&&&&if&(i&%&2&==&0)&{
&&&&&&&&self.stringA&=&@"a&very&long&string";
&&&&else&{
&&&&&&&&self.stringA&=&@"string";
&&&&NSLog(@"Thread&A:&%@\n",&self.stringA);
//thread&B
for&(int&i&=&0;&i&=&10)&{
&&&&&&&&NSString*&subStr&=&[self.stringA&substringWithRange:NSMakeRange(0,&10)];
&&&&NSLog(@"Thread&B:&%@\n",&self.stringA);
}虽然stringA是atomic的property，而且在取substring的时候做了length判断，线程B还是很容易crash，因为在前一刻读length的时候self.stringA = @"a very long string";，下一刻取substring的时候线程A已经将self.stringA = @"string";，立即出现out of bounds的Exception，crash，多线程不安全。同样的场景还存在对集合类操作的时候，比如：@property&(atomic,&strong)&NSArray*&&&&&&&&&&&&&&&&&
//thread&A
for&(int&i&=&0;&i&<&100000;&i&++)&{
&&&&if&(i&%&2&==&0)&{
&&&&&&&&self.arr&=&@[@"1",&@"2",&@"3"];
&&&&else&{
&&&&&&&&self.arr&=&@[@"1"];
&&&&NSLog(@"Thread&A:&%@\n",&self.arr);
//thread&B
for&(int&i&=&0;&i&=&2)&{
&&&&&&&&NSString*&str&=&[self.arr&objectAtIndex:1];
&&&&NSLog(@"Thread&B:&%@\n",&self.arr);
}同理，即使我们在访问objectAtIndex之前做了count的判断，线程B依旧很容易crash，原因也是由于前后两行代码之间arr所指向的内存区域被其他线程修改了。所以你看，真正需要操心的是这一类内存区域的访问，即使声明为atomic也没有用，我们平常App出现莫名其妙难以重现的多线程crash多是属于这一类，一旦在多线程的场景下访问这类内存区域的时候，要提起十二分的小心。如何避免这类crash后面会谈到。Property多线程安全小结：简而言之，atomic的作用只是给getter和setter加了个锁，atomic只能保证代码进入getter或者setter函数内部时是安全的，一旦出了getter和setter，多线程安全只能靠程序员自己保障了。所以atomic属性和使用property的多线程安全并没什么直接的联系。另外，atomic由于加锁也会带来一些性能损耗，所以我们在编写iOS代码的时候，一般声明property为nonatomic，在需要做多线程安全的场景，自己去额外加锁做同步。如何做到多线程安全？讨论到这里，其实怎么做到多线程安全也比较明朗了，关键字是atomicity（原子性），只要做到原子性，小到一个primitive type变量的访问，大到一长段代码逻辑的执行，原子性能保证代码串行的执行，能保证代码执行到一半的时候，不会有另一个线程介入。原子性是个相对的概念，它所针对的对象，粒度可大可小。比如下段代码：if&(self.stringA.length&>=&10)&{
&&&&NSString*&subStr&=&[self.stringA&substringWithRange:NSMakeRange(0,&10)];
}是非原子性的。但加锁以后：//thread&A
[_lock&lock];
for&(int&i&=&0;&i&=&10)&{
&&&&NSString*&subStr&=&[self.stringA&substringWithRange:NSMakeRange(0,&10)];
[_lock&unlock];整段代码就具有原子性了，就可以认为是多线程安全了。再比如：if&(self.arr.count&>=&2)&{
&&&&NSString*&str&=&[self.arr&objectAtIndex:1];
}是非原子性的。而//thread&A
[_lock&lock];
for&(int&i&=&0;&i&=&2)&{
&&&&NSString*&str&=&[self.arr&objectAtIndex:1];
[_lock&unlock];是具有原子性的。注意，读和写都需要加锁。这也是为什么我们在做多线程安全的时候，并不是通过给property加atomic关键字来保障安全，而是将property声明为nonatomic（nonatomic没有getter，setter的锁开销），然后自己加锁。如何使用哪种锁？iOS给代码加锁的方式有很多种，常用的有：@synchronized(token)NSLockdispatch_semaphore_tOSSpinLock这几种锁都可以带来原子性，性能的损耗从上至下依次更小。我个人建议是，在编写应用层代码的时候，除了OSSpinLock之外，哪个顺手用哪个。相较于这几个锁的性能差异，代码逻辑的正确性更为重要。而且这几者之间的性能差异对用户来说，绝大部分时候都感知不到。当然我们也会遇到少数场景需要追求代码的性能，比如编写framework，或者在多线程读写共享数据频繁的场景，我们需要大致了解锁带来的损耗到底有多少。官方文档有个数据，使用Intel-based iMac with a 2 GHz Core Duo processor and 1 GB of RAM running OS X v10.5测试，获取mutex有大概0.2ms的损耗，我们可以认为锁带来的损耗大致在ms级别。Atomic Operations其实除了各种锁之外，iOS上还有另一种办法来获取原子性，使用Atomic Operations，相比锁的损耗要小一个数量级左右，在一些追求高性能的第三方Framework代码里可以看到这些Atomic Operations的使用。这些atomic operation可以在/usr/include/libkern/OSAtomic.h中查到：比如_intA&++;是非原子性的。而OSAtomicIncrement32(&(_intA));是原子性的，多线程安全的。Atomic Operation只能应用于32位或者64位的数据类型，在多线程使用NSString或者NSArray这类对象的场景，还是得使用锁。大部分的Atomic Operation都有OSAtomicXXX，OSAtomicXXXBarrier两个版本，Barrier就是前面提到的memory barrier，在多线程多个变量之间存在依赖的时候使用Barrier的版本，能够保证正确的依赖顺序。对于平时编写应用层多线程安全代码，我还是建议大家多使用@synchronized，NSLock，或者dispatch_semaphore_t，多线程安全比多线程性能更重要，应该在前者得到充分保证，犹有余力的时候再去追求后者。尽量避免多线程的设计无论我们写过多少代码，都必须要承认多线程安全是个复杂的问题，作为程序员我们应该尽可能的避免多线程的设计，而不是去追求高明的使用锁的技能。后面我会写一篇文章，介绍函数式编程及其核心思想，即使我们使用非函数式的编程语言，比如Objective C，也能极大的帮助我们避免多线程安全的问题。总结iOS下多线程不安全的分析至此结束了，如何编写多线程安全的代码，说到底还是在于对memory layout和原子性的理解，也希望这篇文章将atomic和nonatomic的真正区别解释清楚了:)。欢迎关注公众号：MrPeakTech
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量7130点击量3966点击量3934点击量3495点击量3469点击量3369点击量3176点击量3097点击量2857
&2016 Chukong Technologies,Inc.
京公网安备89IOS 多线程，线程同步的三种方式_永恒科技_天涯博客
分享Java核心技术，IT信息，为国内众多的Java爱好者分享Java技术，提供Java专题文章、Java内容信息、疯狂java培训www.fkjava.org
今日访问：[$DayVisitCount$]
总访问量：22390
开博时间：
博客排名：45173
(11)(19)(26)(48)(41)(50)(56)(33)(53)(56)(51)(64)(47)(64)(60)(34)(45)(41)(35)(36)(26)
　　本文主要是讲述 IOS 多线程，线程同步的三种方式，更多IOS技术知识，请登陆疯狂软件教育官网。
　　一般情况下我们使用线程，在多个线程共同访问同一块资源。为保护线程资源的安全和线程访问的正确性。
　　在IOS中我们一般情况下使用以下三种线程同步代码方式：
　　第一种和第二种代码同步的使用方法，一般情况下我们只需要使用NSLock和NSCondition申明2个属性。然后给此属
　　性赋对应的值。那么即可作为安全防控的线程手段。
　　同时也可以保证线程的资源安全。
　　1：NSLock方式
　　[xxxlock lock] //上锁
　　同步代码块
　　[xxxlock unlock]//解锁
　　2：NSCondition方式
　　[xxxCondition lock] //上锁
　　同步代码块
　　[xxxCondition unlock]//解锁
　　第三种方式：在使用synchronized的时候，括号中我们一般情况下只需要传一个self即可。同步代码块 当有线程
　　进去之后会把括号里面对象的锁旗标锁上，其他线程会在外面等着 当进去的线程出去的时候会把锁打开 其余线程
　　再进一个。这样才能保护线程放问资源的安全性。
　　3：@synchronized( 同一对象){
　　线程执行代码;
　　线程资源防控示例代码：
　　[objc]view plaincopyprint?在CODE上查看代码片派生到我的代码片
　　-(void)sellTickets{
　　while (YES) {
　　NSString *name = [NSThread currentThread].
　　// 同步代码块 当有线程进去之后会把括号里面对象的锁旗标锁上，其他线程会在外面等着 当进去的线程
　　出去的时候会把锁打开 其余线程再进一个
　　// @synchronized(self){
　　// [self.myLock lock];
　　[self.myCondition lock];
　　NSLog(@"%@开始卖%d号票",name,self.selledCount+1);
　　[NSThread sleepForTimeInterval:.2];
　　self.selledCount++;
　　NSLog(@"%@卖掉了%d号票，还剩%d张",name,self.selledCount,self.totalCount-
　　self.selledCount);
　　// [self.myLock unlock];
　　[self.myCondition unlock];
　　疯狂软件教育拥有最专业的疯狂iOS学习线路图，不仅证明疯狂软件iOS无与伦比的课程深度，也证明了疯狂软件iOS深厚的技术底蕴;同时也指引了iOS学习者的自学方向。iOS培训采用全新的iMac苹果一体机教学，疯狂软件教育重点培养学员理解软件开发过程，形成良好的编码习惯，能独立完成iPhone手机和iPad平板电脑上App 开发，积累一定的项目经验，能满足企业对iOS相关的人才需求，短期内成就高薪iOS开发人才。如需了解更多，可以咨询QQ:抢座热线：020- 咨询QQ：可登陆疯狂软件教育官网查询。相关文章链接：
......待续
在多线程简介中，我已经说明过了，为了提高界面的流畅度以及用户体验。我们务必要把耗时的操作放到别的线程中去执行，千万不要阻塞主线程。
iOS中有以下3种多线程编程方法：
Grand Centeral Dispatch(GCD)
NSOperation和NSOperationQueue
1.NSThread
这是最轻量级的多线程的方法，使用起来最直观的多线程编程方法。但是因为需要自己管理线程的生命周期，线程同步。经常使用NSThread进行调试，在实际项目中不推荐使用。
//获取当前线程
NSThread *current = [NSThread currentThread];
//获取主线程
NSThread *main = [NSThread mainThread];
NSLog(@&当前线程 --- %@&,current);
NSLog(@&主线程 --- %@&,main);
控制台输出结果：
22:30:29.572 多线程demo[] 当前线程 --- &NSThread: 0x7fc0e1401dc0&{number = 1, name = main}
22:30:29.572 多线程demo[] 主线程 --- &NSThread: 0x7fc0e1401dc0&{number = 1, name = main}
从结果我们看出当前的线程就是主线程，number相当于线程的id,name是线程的名称,主线程的number就是1
阻塞线程：
//阻塞线程3秒
[NSThread sleepForTimeInterval:3];
[NSThread sleepUntilDate:[NSDate dateWithTimeIntervalSinceNow:3]];
2.GCD(Grand Central Dispatch)
GCD是基于C语言底层API实现的一套多线程并发机制，非常的灵活方便，在实际的开发中使用很广泛。
简单来说CGD就是把操作放在队列中去执行。
你只需定义好操作和队列就可以了，不需要直接控制线程的创建和销毁，线程的生命周期由队列来管理。
队列：负责操作的调度和执行，有先进先出(FIFO)的特点。也就是说先加入队列的操作先执行，后加入的后执行。
队列有两种：
串行队列：
队列中的操作只会按顺序执行，你可以想象成单窗口排队。
并行队列：
队列中的操作可能会并发执行，这取决与操作的类型，你可以想象成多窗口排队。
//创建串行队列
dispatch_queue_t q = dispatch_queue_create(&my_serial_queue&, DISPATCH_QUEUE_SERIAL);
//创建并行队列
dispatch_queue_t q = dispatch_queue_create(&my_concurrent_queue&, DISPATCH_QUEUE_CONCURRENT);
my_serial_queue和my_concurrent_queue是队列的名字标签，为了与其他的队列区分，在一个项目里面必须是唯一的。
DISPATCH_QUEUE_SERIAL表示串行队列
DISPATCH_QUEUE_CONCURRENT表示并行队列
操作同样也分两种类型：
同步操作：只会按顺序执行，执行顺序是确定的。
异步操作：在串行队列中执行顺序确定，在并行队列中执行顺序不确定
使用block来定义操作要执行的代码，q是已经定义好的，操作要加入的队列
//定义同步操作
dispatch_sync(q, ^{
//要执行的代码
//定义异步操作
dispatch_async(q, ^{
//要执行的代码
下面我们看一下同步，异步操作加入到串行和并行队列里面，执行的顺序和特点：
1.同步操作不管加入到何种队列，只会在主线程按顺序执行
dispatch_queue_t q_serial = dispatch_queue_create(&my_serial_queue&, DISPATCH_QUEUE_SERIAL);
dispatch_queue_t q_concurrent = dispatch_queue_create(&my_concurrent_queue&, DISPATCH_QUEUE_CONCURRENT);
for (int i = 0; i & 5; ++i) {
dispatch_sync(q_serial, ^{
NSLog(@&串行队列里的同步任务 %@ %d&, [NSThread currentThread], i);
for (int i = 0; i & 5; ++i) {
dispatch_sync(q_concurrent, ^{
NSLog(@&并行队列里的同步任务 %@ %d&, [NSThread currentThread], i);
下面是控制台输出结果：
00:40:36.862 01.GCD演练[] 串行队列里的同步任务 &NSThread: 0x7ff&{number = 1, name = main} 0
00:40:36.863 01.GCD演练[] 串行队列里的同步任务 &NSThread: 0x7ff&{number = 1, name = main} 1
00:40:36.863 01.GCD演练[] 串行队列里的同步任务 &NSThread: 0x7ff&{number = 1, name = main} 2
00:40:36.863 01.GCD演练[] 串行队列里的同步任务 &NSThread: 0x7ff&{number = 1, name = main} 3
00:40:36.863 01.GCD演练[] 串行队列里的同步任务 &NSThread: 0x7ff&{number = 1, name = main} 4
00:40:36.863 01.GCD演练[] 并行队列里的同步任务 &NSThread: 0x7ff&{number = 1, name = main} 0
00:40:36.863 01.GCD演练[] 并行队列里的同步任务 &NSThread: 0x7ff&{number = 1, name = main} 1
00:40:36.863 01.GCD演练[] 并行队列里的同步任务 &NSThread: 0x7ff&{number = 1, name = main} 2
00:40:36.864 01.GCD演练[] 并行队列里的同步任务 &NSThread: 0x7ff&{number = 1, name = main} 3
00:40:36.864 01.GCD演练[] 并行队列里的同步任务 &NSThread: 0x7ff&{number = 1, name = main} 4
2.异步操作只在非主线程的线程执行，在串行队列中异步操作会在新建的线程中按顺序执行。
dispatch_queue_t q_serial = dispatch_queue_create(&my_serial_queue&, DISPATCH_QUEUE_SERIAL);
for(int i = 0; i & 5; ++i){
dispatch_async(q_serial, ^{
NSLog(@&串行队列 -- 异步任务 %@ %d&, [NSThread currentThread], i);
因为是异步操作，所以会新建一个线程。又因为加入到串行队列中，所以所有的操作只会按顺序执行。
01:03:22.372 01.GCD演练[] 串行队列 -- 异步任务 &NSThread: 0x7fb593d42f50&{number = 2, name = (null)} 0
01:03:23.373 01.GCD演练[] 串行队列 -- 异步任务 &NSThread: 0x7fb593d42f50&{number = 2, name = (null)} 1
01:03:24.374 01.GCD演练[] 串行队列 -- 异步任务 &NSThread: 0x7fb593d42f50&{number = 2, name = (null)} 2
01:03:25.375 01.GCD演练[] 串行队列 -- 异步任务 &NSThread: 0x7fb593d42f50&{number = 2, name = (null)} 3
01:03:26.376 01.GCD演练[] 串行队列 -- 异步任务 &NSThread: 0x7fb593d42f50&{number = 2, name = (null)} 4
3.异步操作，并行队列
dispatch_queue_t q_concurrent = dispatch_queue_create(&my_concurrent_queue&, DISPATCH_QUEUE_CONCURRENT);
for(int i = 0; i & 5; ++i){
dispatch_async(q_concurrent, ^{
NSLog(@&并行队列 -- 异步任务 %@ %d&, [NSThread currentThread], i);
理论上并行队列会给每一个异步操作新建线程，然后让所有的任务并发执行。但是实际上系统能创建的线程数量是有限的，当创建的线程达到最大线程数以后，后面的异步操作就需要等待前面的操作执行完毕才能得到执行。哪个线程操作执行完毕，就把等待的异步任务安排到哪个线程。直到所有的操作执行完毕。
你可以把上述代码的循环次数改成5000就可以观察到此现象。
01:14:15.282 01.GCD演练[] 并行队列 -- 异步任务 &NSThread: 0x7fb3b841b0a0&{number = 4, name = (null)} 3
01:14:15.282 01.GCD演练[] 并行队列 -- 异步任务 &NSThread: 0x7fb3b8514da0&{number = 3, name = (null)} 0
01:14:15.282 01.GCD演练[] 并行队列 -- 异步任务 &NSThread: 0x7fb3b8604db0&{number = 5, name = (null)} 2
01:14:15.282 01.GCD演练[] 并行队列 -- 异步任务 &NSThread: 0x7fb3b86119d0&{number = 2, name = (null)} 1
01:14:15.285 01.GCD演练[] 并行队列 -- 异步任务 &NSThread: 0x7fb3b87011f0&{number = 6, name = (null)} 4
3.NSOperation & NSOperationQueue
虽然GCD的功能已经很强大了，但是它使用的API依然是C语言的。在某些时候，在面向对象的objective-c中使用起来非常的不方便和不安全。
所以苹果公司把GCD中的操作抽象成NSOperation对象，把队列抽象成NSOperationQueue对象。
抽象为NSOperation & NSOperationQueue以后的好处有一下几点：
代码风格统一了，我们不用在面向对象的objective-C中写面对过程的C语言代码了。
我们知道在GCD中操作的执行代码都是写在匿名的block里面，那么我们很难做到给操作设置依赖关系以及取消操作。这些功能都已经封装到NSOperation对象里面了。^-^
NSOperationQueue对象比GCD中队列更加的强大和灵活，比如：设置并发操作数量，取消队列中所有操作。
NSOperation分为NSInvocationOperation和NSBlockOperation
NSInvocationOperation的使用
//首先定义一个NSOperationQueue对象
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
NSInvocationOperation *op = [[NSInvocationOperation alloc] initWithTarget:self selector:@selector(operationAction:) object:@&这里可以穿参数&];
[queue addOperation:op];//把操作加入队列中即开始执行
- (void)operationAction:(id)obj
NSLog(@&%@ - obj : %@&, [NSThread currentThread], obj);
02:55:19.067 多线程demo[] &NSThread: 0x7f9dfa443510&{number = 2, name = (null)} - obj : 这里可以穿参数
NSBlockOperation的使用
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
NSBlockOperation *op = [NSBlockOperation blockOperationWithBlock:^{
[self operationAction:@&这是NSBlockOperation&];
[queue addOperation:op];
02:56:11.812 多线程demo[] &NSThread: 0x7fa983f10a50&{number = 2, name = (null)} - obj : 这是NSBlockOperation
设置依赖关系(执行顺序)
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
NSInvocationOperation *op1 = [[NSInvocationOperation alloc] initWithTarget:self selector:@selector(operationAction:) object:@&op1&];
NSInvocationOperation *op2 = [[NSInvocationOperation alloc] initWithTarget:self selector:@selector(operationAction:) object:@&op2&];
//op2在op1之后执行
[op2 addDependency:op1];//这里需要注意，一定要在addOperation之前设置依赖关系
[queue addOperation:op1];
[queue addOperation:op2];
02:57:40.283 多线程demo[] &NSThread: 0x7fb663e132d0&{number = 2, name = (null)} - obj : op1
02:57:40.284 多线程demo[] &NSThread: 0x7fb663e132d0&{number = 2, name = (null)} - obj : op2
没有设置依赖关系的输出：
03:00:45.939 多线程demo[] &NSThread: 0x7fe951d0d8a0&{number = 2, name = (null)} - obj : op2
03:00:45.939 多线程demo[] &NSThread: 0x7fe951c24720&{number = 3, name = (null)} - obj : op1
到这里你应该发现了，在NSOperation & NSOperationQueue中，我们不需要再像GCD那样定义操作的类型和队列的类型和控制操作的执行顺序了，你只需要直接设定操作的执行顺序就可以了。
阅读(...) 评论()