你不知道的的 iOS 多线程

程序员用有限的生命去追求无限的知识。

有言在先

首先我不是故意要作标题党的，也不是我要炒冷饭，我只是想换个姿式看多线程，本文大部份内容在分析如何造死锁，奈何功力尚浅，然而再浅，也须要走出第一步。打开你的 Xcode 来验证这些死锁吧。

多线程小知识

如下是实现多线程的三种方式：

• NSThread
• GCD
• NSOperationQueue

关于具体使用的方法再也不具体介绍，让咱们来看看他们鲜为人知的一面

1. 锁的背后

NSLock是基于 POSIX threads 实现的，而 POSIX threads 中使用互斥量同步线程。

互斥量（或称为互斥锁）是 pthread 库为解决这个问题提供的一个基本的机制。互斥量是一个锁，它保证以下三件事情：

• 原子性 - 锁住一个互斥量是一个原子操做，代表操做系统保证若是在你已经锁了一个互斥量，那么在同一时刻就不会有其余线程可以锁住这个互斥量；

• 奇异性 - 若是一个线程锁住了一个互斥量，那么能够保证的是在该线程释放这个锁以前没有其余线程能够锁住这个互斥量；

• 非忙等待 - 若是一个线程（线程1）尝试去锁住一个由线程2锁住的锁，线程1会挂起（suspend）而且不会消耗任何CPU资源，直到线程2释放了这个锁。这时，线程1会唤醒并继续执行，锁住这个互斥量。

2. 关于生命周期

经过 [NSThread exit] 方法使线程退出 ，NSThread 是能够当即终止正在执行的任务（可能会形成内存泄露，这里不深究）。甚至你能够在主线程中执行该操做，会使主线程也退出，app 没法再响应事件。而 cancel 能够经过做为标志位来达到相似目的，若是不作任何处理，仍然会继续执行。

GCD和NSOperationQueue能够取消队列中未开始执行的任务，对于已经开始执行的任务就无能为力了。

实现方式\功能	线程生命周期	取消任务
NSThread	手动管理	当即中止执行
GCD	自动管理	取消队列中未执行的任务
NSOperationQueue	自动管理	取消队列中未执行的任务

3. 并行与并发

看到不少文章里提到 并发队列 ，这里有一个小陷阱，混淆了 并发 和 并行 的概念。咱们先来看看一下他们之间的区别：

从图中能够看到，并行才是真正的多线程，而并发只是在多任务中切换。通常多核CPU能够并行执行多个线程，而单核CPU实际上只有一个线程，多路复用达到接近同时执行的效果。在 iOS 中 dispatch_async 和 globalQueue 从 Xcode 中线程使用状况来看，都达到了并行的效果。

4. 队列与线程

队列是保存以及管理任务的，将任务加到队列中，任务会按照加入到队列中前后顺序依次执行。若是是全局队列和并发队列，则系统会根据系统资源去建立新的线程去处理队列中的任务，线程的建立、维护和销毁由操做系统管理，还有队列自己是线程安全的。

使用 NSOperationQueue 实现多线程的时候是能够控制线程总数及线程依赖关系的，而 GCD 只能选择并发或者串行队列。

资源竞争

多线程同时执行任务能提升程序的执行效率和响应时间，可是多线程不可避免地遇到同时操做同一资源的状况。前段时间看到的一个资源竞争的问题为例：

@property (nonatomic, strong) NSString *target; 
dispatch_queue_t queue = dispatch_queue_create("parallel", DISPATCH_QUEUE_CONCURRENT);
for (int i = 0; i < 1000000 ; i++) { 
    dispatch_async(queue, ^{ 
        self.target = [NSString stringWithFormat:@"ksddkjalkjd%d",i]; 
    }); 
}
复制代码

解决办法：

• @property (nonatomic, strong) NSString *target;将nonatomic改为atomic。
• 将并发队列 DISPATCH_QUEUE_CONCURRENT 改为串行队列 DISPATCH_QUEUE_SERIAL。
• 异步执行dispatch_async 改为同步执行dispatch_sync。
• 赋值使用@synchronized 或者上锁。

这些方法都是从避免同时访问的角度来解决该问题，有更好的方法欢迎分享。

花样死锁

任何事情都有两面性，就像多线程能提高效率的同时，也会形成资源竞争的问题。而锁在保证多线程的数据安全的同时，粗枝大叶之下也容易发生问题，那就是 死锁 。

1. NSOperationQueue

鉴于 NSOperationQueue 高度封装，使用起来很是简单，通常不会出什么幺蛾子，下面的案例展现了一个很差示范，一般咱们经过控制 NSOperation 之间的从属关系，来达到有序执行任务的效果，可是若是互相从属或者循环从属都会形成全部任务没法开始。

NSBlockOperation *blockOperation1 = [NSBlockOperation blockOperationWithBlock:^{
        NSLog(@"lock 1 start");
        [NSThread sleepForTimeInterval:1];
        NSLog(@"lock 1 over");
    }];
    
    NSBlockOperation *blockOperation2 = [NSBlockOperation blockOperationWithBlock:^{
        NSLog(@"lock 2 start");
        [NSThread sleepForTimeInterval:1];
        NSLog(@"lock 2 over");
    }];
    
    NSBlockOperation *blockOperation3 = [NSBlockOperation blockOperationWithBlock:^{
        NSLog(@"lock 3 start");
        [NSThread sleepForTimeInterval:1];
        NSLog(@"lock 3 over");
    }];
    
    // 循环从属
    [blockOperation2 addDependency:blockOperation1];
    [blockOperation3 addDependency:blockOperation2];
    [blockOperation1 addDependency:blockOperation3]; // 循环的罪魁祸首

    // 互相从属
    //[blockOperation1 addDependency:blockOperation2];
    //[blockOperation2 addDependency:blockOperation1];

    [_operationQueue addOperation:blockOperation1];
    [_operationQueue addOperation:blockOperation2];
    [_operationQueue addOperation:blockOperation3];
复制代码

有没有人试过下面这种状况，若是好奇就试试吧！

[blockOperation1 addDependency:blockOperation1];
复制代码

2. GCD

大多数开发者都知道在主线程里同步执行任务会形成死锁，一块儿来看看还有哪些状况下会形成死锁或相似问题。

a. 在主线程同步执行 形成 EXC_BAD_INSTRUCEION 错误:

- (void)deadlock1 {
    dispatch_sync(dispatch_get_main_queue(), ^{
        NSLog(@"task 1 start");
        [NSThread sleepForTimeInterval:1.0];
        NSLog(@"task 1 over");
    });
}
复制代码

b. 和主线程同步执行相似，在串行队列中嵌套使用同步执行任务，同步队列 task1 执行完成后才能执行 task2 ，而 task1 中嵌套了task2 致使 task1 注定没法完成。

- (void)deadlock2 {
    dispatch_queue_t queue = dispatch_queue_create("com.xietao3.sync", DISPATCH_QUEUE_SERIAL);

    dispatch_sync(queue, ^{ // 此处异步一样会形成互相等待
        NSLog(@"task 1 start");
        dispatch_sync(queue, ^{
            NSLog(@"task 2 start");
            [NSThread sleepForTimeInterval:1.0];
            NSLog(@"task 2 over");
        });
        NSLog(@"task 1 over");
    });
}
复制代码

嵌套同步执行任务确实很容易出 bug ，但不是绝对，将同步队列DISPATCH_QUEUE_SERIAL 换成并发队列 DISPATCH_QUEUE_CONCURRENT 这个问题就迎刃而解。修改为并发队列后案例中 task1 仍然要先执行完嵌套在其中的 task2 ，而 task2 开始执行时，并发队列不会发生互相等待致使阻塞问题 ， task2 执行完成后 task1 继续执行。

c. 在不少人印象中，异步执行不容易发生互相等待的状况，确实，即便是串行队列，异步任务会等待当前任务执行后再开始，除非你加了一些不健康的佐料。

- (void)deadlock3 {
    dispatch_queue_t queue = dispatch_queue_create("com.xietao3.asyn", DISPATCH_QUEUE_SERIAL);
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
    
    dispatch_async(queue, ^{
        __block NSString *str = @"xietao3";                             // 线程1 建立数据
        dispatch_async(queue, ^{
            str = [NSString stringWithFormat:@"%ld",[str hash]];        // 线程2 加工数据
            dispatch_semaphore_signal(semaphore);
        });
        dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
        NSLog(@"%@",str);                                               // 线程1 使用加工后的数据
    });
}
复制代码

d. 常规死锁，在已经上锁的状况下再次上锁，造成彼此等待的局面。

if (!_lock) _lock = [NSLock new];
  dispatch_queue_t queue = dispatch_queue_create("com.xietao3.sync", DISPATCH_QUEUE_CONCURRENT);
    
    [_lock lock];
    dispatch_sync(queue, ^{
        [_lock lock];
        [NSThread sleepForTimeInterval:1.0];
        [_lock unlock];
    });
    [_lock unlock];
复制代码

要解决也比较简单，将NSLock换成递归锁NSRecursiveLock，递归锁就像普通的门锁，顺时针转一圈加锁后，逆时针一圈即解锁；而若是顺时针两圈，一样逆时针两圈便可解锁。下面来一个递归的例子：

// 如下代码能够理解为顺时针转10圈上锁，逆时针转10圈解锁
- (void)recursivelock:(int)count {
    if (count>10) return;
    count++;
    if (!_recursiveLock) _recursiveLock = [NSRecursiveLock new];

    [_recursiveLock lock];
    NSLog(@"task%d start",count);
    [self recursivelock:count];
    NSLog(@"task%d over",count);
    [_recursiveLock unlock];
}
复制代码

3. 其余

除了上面提到的互斥锁和递归锁，其余的锁还有：

• OSSpinLock(自旋锁)
• pthread_mutex（OC中锁的底层实现）
• NSConditionLock（条件锁，对于新手更容易产生死锁）
• NSCondition（条件锁的底层实现）
• @synchronized（对象锁）

大部分锁触发死锁的状况和互斥锁基本一致，NSConditionLock使用起来会更加灵活，而自旋锁虽然性能爆表，可是存在漏洞，但愿了解更多关于锁的知识能够点这里，在看的同时不要忘记亲自动手验证一下，边看边写边验证，记得更加深入。

总结

关于多线程、锁的文章已经烂大街了，本文尽量地重新的角度来看问题，尽可能不写那些重复的内容，但愿对你有所帮助，若是文中内容有误，欢迎指出。

转载请注明原文：juejin.im/post/59c13d…