并发机制研究

在iOS中，进程或应用程序由一个或多个线程组成。操作系统调度程序彼此独立地管理线程。

进程和线程都是一个时间段的描述，是CPU工作时间段的描述。
进程是系统资源分配的最小单位，线程是cpu调度资源的最小单位

单核设备通过时间切片time-slicing的方法实现并发。它们运行一个线程，执行上下文切换，然后运行另一个线程。
多核设备通过parallelism同时执行多个线程

不同设备并发机制

GCD建立在线程之上，它负责管理共享线程池。使用GCD，可以添加代码块或工作项来调度队列dispatch queues，GCD决定执行它们的线程

GCD通过一个名为DispatchQueue的类来操作调度队列。将工作单位提交到此队列，GCD以FIFO顺序（先进先出）执行它们，保证提交的第一个任务是第一个启动的任务

GCD提供三种主要类型的队列
· Main queue 主队列：在主线程上运行，是一个串行队列。
· Global queues 全局队列 整个系统共享的并发队列。有四个优先级 high, default, low, backgound。
· Custome queues 自定义队列，可以自己创建的一个串行或并发的队列。但实际上还是请求一个全局队列

至于线程和队列的关系，我看了其他的资料，觉得这个说得蛮有道理
https://www.jianshu.com/p/0763add61358

int main(void) {
dispatch_queue_t queue = dispatch_queue_create(“com.somecompany.queue”, nil);
dispatch_async(queue, ^{ //任务1
    [self goDoSomethingLongAndInvolved]; 
    dispatch_sync(queue, ^{ // 任务2
        NSLog(@"Situation 1"); 
    });
});
return 0;
}

以上代码调用会死锁，任务2和任务1互相等待，程序会崩溃

int main(void) {
dispatch_queue_t queue = dispatch_queue_create(“com.somecompany.queue”, nil);
dispatch_sync(queue, ^{ // 任务1
        NSLog(@"Situation 1"); 
});
return 0;
}

这种场景正常，queue是主线程生成的串行队列

int main(void) {
dispatch_queue_t queue = dispatch_get_main_queue();
dispatch_sync(queue, ^{ // 任务1
        NSLog(@"Situation 1"); 
});
return 0;
}

这种会死锁，queue是主队列，也是串行队列

为什么都是串行队列，场景3卡死是因为本身sync函数调用本身就在主队列中

首先，死锁的原因第一个是同步提交（可以类似等待操作），这种方式会阻塞当前线程，其次是相同队列，在场景3，任务1处于主线程，主队列，所以里面的打印需要等主队列执行完“return 0”才能执行，但“return 0”需要主队列执行完打印才能执行，这样就造成了死锁。

接下来看另一种场景

dispatch_queue_t serialQueue = dispatch_queue_create("fjajfklj", DISPATCH_QUEUE_SERIAL);
 dispatch_async(serialQueue, ^{
        NSLog(@"111");
        NSLog(@"%@",[NSThread currentThread]);
    });
    dispatch_async(serialQueue, ^{
        NSLog(@"222");
        NSLog(@"%@",[NSThread currentThread]);
    });
    dispatch_async(serialQueue, ^{
        NSLog(@"333");
        NSLog(@"%@",[NSThread currentThread]);
    });
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        dispatch_async(serialQueue, ^{
            NSLog(@"444");
            NSLog(@"%@",[NSThread currentThread]);
        });
    });

打印如下

2018-09-13 16:41:01.792392+0800 ConcurrentDemo[21815:1015633] 111
2018-09-13 16:41:01.792640+0800 ConcurrentDemo[21815:1015633] <NSThread: 0x600000465040>{number = 3, name = (null)}
2018-09-13 16:41:01.792743+0800 ConcurrentDemo[21815:1015633] 222
2018-09-13 16:41:01.793222+0800 ConcurrentDemo[21815:1015633] <NSThread: 0x600000465040>{number = 3, name = (null)}
2018-09-13 16:41:01.793740+0800 ConcurrentDemo[21815:1015633] 333
2018-09-13 16:41:01.793833+0800 ConcurrentDemo[21815:1015633] <NSThread: 0x600000465040>{number = 3, name = (null)}
2018-09-13 16:41:07.281068+0800 ConcurrentDemo[21815:1015636] 444
2018-09-13 16:41:07.281254+0800 ConcurrentDemo[21815:1015636] <NSThread: 0x60000027aa80>{number = 4, name = (null)}

输出444的有几率在另一个线程进行，但是他们同属于一个串行队列，所不同的444延迟了几秒执行。

里面的主要原因就是runloop的原因，串行队列里面所调度的线程，在一个runloop的区间内用完就释放了

这段代码运行于viewDidLoad{}里面。可以认为是主队列的一个任务片段，这个任务片段处于同一个runloop周期内，前面3个dispatch_async是属于这个任务片段内的一个小片段，也就是说，这3个小片段都属于主队列的runloop周期里面，且是异步操作，因此能够很快返回。

至于最后一个dispatch_asnyc因为延迟函数，在主runloop当前的循环的下一个或者几个循环里面。上面创造的thread已经消亡，所以主runloop会去新建一个线程。

GCD实现原理

GCD有一个底层线程池，这个池中存放的是一个个线程，线程可以复用，一段时间没有被调用的话，这个线程就会被销毁。开多少线程是由底层线程池决定，池是系统自动来维护，不需要我们程序员来维护。

我们在使用同步提交的时候可以看到不会创建新的线程，异步提交的时候一般会创建新的线程。因为开不开新线程，并不是异步提交来决定的，而是由队列这个线程调度的掌控者来决定的。

因为每个队列下面都维护线程池，如果线程池的线程有空，我为何要重新开辟一个新线程呢？

至于死锁的问题，我查看了一下bestswifter(https://bestswifter.com/deep-gcd/)
的博客和查看了GCD的源码
GCD文档上写了调用dispatch_sync的时候，指定的队列不应该是当前上下文的队列，不然会造成死锁

Calls to dispatch_sync() targeting the current queue will result in dead-lock.