美文网首页
并发机制研究

并发机制研究

作者: 程序狗 | 来源:发表于2018-09-14 16:36 被阅读9次

    在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.
    

    相关文章

      网友评论

          本文标题:并发机制研究

          本文链接:https://www.haomeiwen.com/subject/lnxwgftx.html