【iOS】 GCD-资源竞争和死锁篇

GCD-基础篇提出了三个问题，这里我们就这三个问题，在基于GCD-基础篇知识之上给出几种解决方案，仅供参考学习。

1.死锁

停止等待事件导致多个线程相互持续等待。

如在主线程中执行如下代码会死锁：

dispatch_queue_t mainQueue = dispatch_get_main_queue();
dispatch_sync(mainQueue, ^{
    /*
     主线程停在同步提交任务这一步，导致block不会执行，
      block不执行，同步提交任务就会停留在主线程中一直等待，导致死锁
     
      当前队列是主队列，block被提交到了当前队列
     */
    NSLog(@"Hello?");
});

假设在改代码之前，主队列为空，dispatch_sync是一个向主队列添加任务的操作，进入主队列，编号为1，然后它并不结束，会继续占用主线程，等到block执行完毕，问题在于，block操作被提交到队列中编号为2，根据FIFO,只有编号1执行完毕，编号2才能执行，现在编号1占用主线程，编号2不能进入主线程执行，造成死锁。

还有如下几种情况都会造成死锁：
当前队列是主队列，使用dispatch_sync函数，block被提交到了当前队列

  dispatch_async(mainQueue, ^{
   
    dispatch_sync(mainQueue, ^{
        
        /*
         同样由于主队列任务互相等待造成死锁
         */
    });
    
});

Serial Dispatch Queue导致死锁
当前队列是queue，使用dispatch_sync函数，block被提交到了当前队列

dispatch_queue_t queue = dispatch_queue_create("com.example.myqueue", NULL);
dispatch_async(queue, ^{
    
    dispatch_sync(queue, ^{
       /*
        无论queue是同步等待队列还是异步等待队列，都会造成死锁
        当queue是异步等待队列，最外层提交后，GCD只会成一条线程1，因为只有一
          个block1被提交，然后在线程1中执行block1任务，block1的任务是再次同步提交新的block2到异步等待队列，
          GCD会为block2开辟线程2，执行block2，执行完毕，两条线程同时销毁，不会死锁。
        当queue是同步队列serial queue时正好相反会死锁。
        */
    });
});

另外dispatch_barrier_sync函数作用是等待提交的处理全部执行结束后，再追加处理到Dispatch Queue中，此外它还和dispatch_sync函数一样，会等待提交处理的执行结束。

解决方案：
对于dispatch_sync同步等待执行函数要谨慎使用。

2.资源竞争

资源竞争，是指多个操作任务同时操作同一个数据源或内存产生的问题。

解决方案：
假设对某个文件file要进行读写操作，如下：
blk0_read
blk1_read
blk2_read
blk3_write
blk4_read
blk5_read
blk6_read
以上任务中，除了blk3_write是写入，其他都是读取操作，如果读写同时进行就会出现资源竞争，导致数据出错。可以使用以下方法解决：

Serial Dispatch Queue
同步等待队列遵循FIFO,队列中的任务按照顺序呢执行，不会出错，可以将blk操作提交到同步等待队列中按顺序执行。
dispatch_queue_t serialQueue = dispatch

dispatch_barrier_async
将write操作和前后的读操作屏蔽开

/*
 dispatch_barrier_async
 该函数有屏障功能，block被提交到队列中的顺序从前往后为：blk0-blk1-blk2-blk3-blk4-blk5-blk6,
  该屏障函数会将队列中任务分为三段，
 第一段：blk0-blk1-blk2、
 第二段：blk3、
 第三段：blk4-blk5-blk6,
 GCD会先执行第一段，再执行第二段，最后第三段（多条线程）
 
 */
dispatch_queue_t concurrentQueue = dispatch_queue_create("com.example.myqueue", DISPATCH_QUEUE_CONCURRENT);
dispatch_async(concurrentQueue, ^{/*blk0_read*/});
dispatch_async(concurrentQueue, ^{/*blk1_read*/});
dispatch_async(concurrentQueue, ^{/*blk2_read*/});

dispatch_barrier_async(concurrentQueue, ^{/*blk3_write*/});

dispatch_async(concurrentQueue, ^{/*blk4_read*/});
dispatch_async(concurrentQueue, ^{/*blk5_read*/});
dispatch_async(concurrentQueue, ^{/*blk6_read*/});

dispatch semaphore
信号计数器，可以进行更细微的控制，类似于马路信号的手旗，可通过时举起手旗，不可通过放下手旗。技术信号为0表示等待，技术信号大于等于1减去1而不等待。

假设我们有如下场景，需要对可变数组存入10000个对象，并且在存入之前要做do something处理，do somthing是个很耗时的操作。所以可以使用多线程异步并发的操作：

dispatch_queue_t queue = dispatch_queue_create("com.example.myqueue", DISPATCH_QUEUE_CONCURRENT);


NSMutableArray *array = [NSMutableArray arrayWithCapacity:1];

for (int i = 0; i < 10000; ++i) {
    
    dispatch_async(queue, ^{
       
        /*
          do something
         */
        
        [array addObject:[NSNumber numberWithInt:i]];
        
    });
    
}

使用了上面的操作，可以异步并发的执行添加对象到数组，可以明显提高效率。但是，同一时刻操作同一块array的内存空间会导致内存问题，出现资源竞争，于是对代码进行如下优化：

dispatch_queue_t queue = dispatch_queue_create("com.example.myqueue", DISPATCH_QUEUE_CONCURRENT);

dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);

NSMutableArray *array = [NSMutableArray arrayWithCapacity:1];

for (int i = 0; i < 10000; ++i) {
    
    dispatch_async(queue, ^{
       
        /*
          do something
         */
        
        //信号==0等待，>=1减1不等待进入下一步代码
        dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
        
        [array addObject:[NSNumber numberWithInt:i]];
        
        //信号 +1
        dispatch_semaphore_signal(semaphore);
        
    });
    
}

执行了上面的操作后 do somthing耗时操作会异步的执行，addObject操作在信号技术器的控制下会顺序执行。解决了资源竞争问题，并大大提高了效率。

3.内存消耗

iOS 4.0后，GCD已经可以自动管理realese和retain了，我们只需要谨慎的使用GCD就好了。在上面的例子中将会有很大的内存问题，for循环10000次，等于向队列中添加了10000个block任务，会造成内存暴增，app被杀死，很快我们会想到如下的方法解决：

dispatch_queue_t queue = dispatch_queue_create("com.example.myqueue", DISPATCH_QUEUE_CONCURRENT);

dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);

NSMutableArray *array = [NSMutableArray arrayWithCapacity:1];

for (int i = 0; i < 10000; ++i) {
    
  @autoreleasepool {
    
    dispatch_async(queue, ^{
       
        /*
          do something
         */
        
        //信号==0等待，>=1减1不等待进入下一步代码
        dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
        
        [array addObject:[NSNumber numberWithInt:i]];
        
        //信号 +1
        dispatch_semaphore_signal(semaphore);
        
    });
    
  }
}

加入自动释放池，可以让不再使用的对象及时释放，可是运行app问题依然存在，因为自动释放池只是及时释放掉不被使用的OC对象占用内存，这里导致问题的根源在于队列加入任务过多内存暴增，争抢线程资源等，所有解决办法只能是控制加入队列中的任务数量，或者进行分组管理，等一部分执行完毕再进行下一组提交，具体的实现这里不再讲解。

最后附上一张个人总结的GCD总结图