多线程方案：
比较常用的是GCD，是直接用Block去写代码的。使代码比较紧凑。
GCD常用函数
同步执行任务：dispatch_sync(dispatch_queue_t queue, dispatch_block_t block);
异步执行任务：dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
控制任务的执行顺序：
dispatch_barrier_async：栅栏函数，它等待所有位于barrier函数之前的操作执行完毕后执行,并且在barrier函数执行之后,barrier函数之后的操作才会得到执行。并且需要在异步并发队列才有效。
dipatch_group：线程组，可以实现A、B、C、任务并发执行，完了之后再通知执行D任务。
各种多线程队列的执行效果：
注意：全局队列也是一个并发队列，主队列是一个串行队列。同步和异步主要影响能不能开启新线程
多线程的安全隐患：当多个线程访问同一块资源时，很容易引发数据错乱和数据安全问题。
面试题
一
NSLog(@"执行任务1");
dispatch_queue_t queue = dispatch_get_main_queue();
dispatch_sync(queue, ^{
NSLog(@"执行任务2");
});
NSLog(@"执行任务3");
以上代码在主线程中执行会产生死锁。dispatch_sync 会立马在当前线程执行任务
二
NSLog(@"执行任务1");
dispatch_queue_t queue = dispatch_get_main_queue();
dispatch_async(queue, ^{
NSLog(@"执行任务2");
});
NSLog(@"执行任务3");
以上代码在主线程执行不会产生死锁。dispatch_async并不会立马执行。打印顺序是任务1、任务3、任务2。
三
NSLog(@"执行任务1");
dispatch_queue_t queue = dispatch_queue_create("myqueue", DISPATCH_QUEUE_SERIAL);
dispatch_async(queue, ^{//block01
NSLog(@"执行任务2");
dispatch_sync(queue, ^{//block02
NSLog(@"执行任务3");
});
NSLog(@"执行任务4");
});
NSLog(@"执行任务5");
以上代码在主线程执行会产生死锁。会生成一个新线程，这个新线程是串行执行任务，先执行block01，然后再执行block02，由于block01在前面，要执行完block01才能执行block02，而block02又必须要等block01执行完，这样就互相等待，产生死锁。
四
dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
dispatch_async(queue, ^{
NSLog(@"1");
[self performSelector:@selector(test) withObject:nil afterDelay:0];
NSLog(@"3");
});
- (void)test{
NSLog(@"2");
}
以上代码只打印了1和3。因为performSelector：withObject：afterDelay方法的本质是往RunLoop里面添加了一个定时器。由于在这个子线程中没有启动RunLoop，所以test方法并不会执行。凡是有afterDelay的方法都是在RunLoop实现的。如果没有afterDelay比如performSelector：withObject：方法则是通过objc_msgSend执行。
死锁总结
使用sync同步执行往当前串行队列中添加任务，这样就会产生死锁
线程同步方案：锁
1、OSSpinLock：（自旋锁），等待锁的线程会处于忙等状态，一直占用着CPU资源。
注意这个锁目前是不安全的，会出现线程优先级反转问题。iOS10之后用os_unfair_lock代替。比如有如下两个线程：
线程1（优先级高）
线程2（优先级低）
如果线程2先进去，加锁了，紧接着线程1又来了，发现锁已经被线程2加了，那么线程1就会出现忙等。因为线程1优先级比较高，所以CPU把资源优先分配给在忙等的线程1，此时优先级低的线程2就无法往下面执行任务了。这样就出现死锁了。
如果不是自旋锁，是互斥锁，就不会出现忙等，线程1就会出现休眠，休眠了，CPU就不会分配资源给线程1了。这样线程2可以往下执行，等执行完了，线程1被唤醒后接着就可以往下执行了。
2、pthread_mutex：（互斥锁）等待锁的线程会处于休眠状态。不会占用CPU资源
3、NSConditionLock：（条件锁，是对mutex的封装），当一条线程进去之后，加锁，由于没有达到条件，就会进入休眠，并且放开锁。当另一条线程执行完任务达到条件后就会通知刚刚等待休眠的线程继续加锁执行任务。
4、NSLock也是对mutex的封装
5、dispatch_semaphore：（信号量）设置信号量来允许多个线程同时访问临界区。
6、@synchronized：（也是对mutex的封装），性能差，它是使用一个对象来生成一把锁，它底层会有一个哈希表，用来保存对象的地址，一个对象地址对应一把锁。
7、pthread_mutex（recursive）：（递归锁），用于递归方法执行
其中os_unfair_lock的性能是最高的但是iOS10才支持，接下来是信号量，然后是pthread_mutex，性能最差的是@synchronized
自旋锁和互斥锁的比较
以下情况用自旋锁
- 预计线程等待锁的时间很短
- 加锁的代码经常被调用，但竞争情况很少发生
- CPU资源不紧张
- 多核处理器
以下情况用互斥锁
- 预计线程等待锁的时间较长
- 单核处理器
- 临界区又IO操作
- 临界区代码复杂或者循环量大
- 临界区竞争非常激烈
atomic和nonatomic
atomic就是对属性的getter和setter方法内部加了线程同步的锁，自旋锁。
注意
但是atomic并不能保证使用属性的过程是线程安全的。比如一个atomic修饰的MutableArray，在使用数组添加删除元素的时候并不是线程安全的，仅仅是set和get方法是线程安全的。
我们不推荐使用atomic，因为属性调用比较频繁，如果每次调用都要加锁解锁那么会消耗CPU性能。
读写安全方案（文件IO操作）
主要是设计两个接口read和write，一个读，一个写，要保证以下情况：
同一时间允许有多条线程同时读
同一时间只允许有一条线程写
同一时间不允许既有写的操作，又有读的操作
像这种多读单写场景，在iOS中的解决方案有：
1、pthread_rwlock：读写锁
2、dispatch_barrier_async：异步栅栏函数
self.queue = dispatch_queue_create("rw_queue", DISPATCH_QUEUE_CONCURRENT);
for (int i = 0; i < 10; i++) {
dispatch_async(self.queue, ^{
[self read];
});
dispatch_async(self.queue, ^{
[self read];
});
dispatch_async(self.queue, ^{
[self read];
});
dispatch_barrier_async(self.queue, ^{
[self write];
});
}
在写的操作前后进行隔离，保证同时只有写的操作。
