我们都知道，如果在使用GCD的sync不当的时候，很容易造成死锁。比如这样：
dispatch_queue_t mainQueue = dispatch_get_main_queue();
NSLog(@"this is task 1");
dispatch_sync(mainQueue, ^{
NSLog(@"this is task 2");
});
NSlog(@"this is task 3");
在这里不得不吐槽下被转载的很多的一篇《五个案例让你明白GCD死锁》，表示我在以前学习的时候直接看第一个案例就晕掉了。作者举了个和上面代码一样的例子，然后如下描述：
首先执行任务1，这是肯定没问题的，只是接下来，程序遇到了同步线程，那么它会进入等待，等待任务2执行完，然后执行任务3。但这是队列，有任务来，当然会将任务加到队尾，然后遵循FIFO原则执行任务。那么，现在任务2就会被加到最后，任务3排在了任务2前面，问题来了：
任务3要等任务2执行完才能执行，任务2由排在任务3后面，意味着任务2要在任务3执行完才能执行，所以他们进入了互相等待的局面。【既然这样，那干脆就卡在这里吧】这就是死锁。
可能作者自己心里是明白的，但不得不说这段表述很容易让人疑惑和误解，把人绕晕了。而且即使我们删掉任务3，这段代码就可以没问题的执行么？显然是禁不起推敲的，把最后一行的NSLog删掉，这段代码一样会死锁。
当然在实际的使用过程中，我们很少会犯这样的错误，然而这样的死锁问题离我们并不远。造成死锁的问题不是自己的线程阻塞自己，而是线程之间相互锁住了，比如：
dispatch_queue_t queue1;
dispatch_queue_t queue2;
- (void)testDeadLock {
queue1 = dispatch_queue_create("com.demo.queue1", DISPATCH_QUEUE_SERIAL);
queue2 = dispatch_queue_create("com.demo.queue2", DISPATCH_QUEUE_SERIAL);
dispatch_async(queue1, ^{
[self taskA];
});
}
- (void)taskA {
dispatch_sync(queue2, ^{
NSLog(@"this is taskA");
[self taskB];
});
}
- (void)taskB {
dispatch_sync(queue1, ^{
NSLog(@"this is taskB");
});
}
这还只是一种简单的情况，事实上，可能在1线程上的A任务调用B任务，B调用C任务，后面这个圈子越来越大，最后X任务同步Y任务到1线程，死锁就是这样造成的，然而对于Y任务来说，他可能对中间的调度并不清楚，从而引起了死锁。
如何避免GCD中的死锁，网上的文章很多，但如果已经发生了，我们如何去查找这种死锁，是一个比较费时费力的工作，然而我们可以换一种思路来定位：是否可以用其他的方法重写sync，并在超时的时候打印出debug信息，这样我们的定位工作就简单多了。用异步的写法代替同步网上有很多方法：使用dispatch_group或者dispatch_barrier_async，其实用信号量实现也很简单：
+ (void)syncTask:(void(^)())task queue:(dispatch_queue_t)queue {
dispatch_semaphore_t sem = dispatch_semaphore_create(0);
dispatch_async(queue, ^{
task();
dispatch_semaphore_signal(sem);
});
dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);
}
这样我们就实现了用async实现了sync的功能了。下面把这个稍加改动，打印出debug信息：
+ (void)syncTask:(void(^)())task queue:(dispatch_queue_t)queue timeOut:(float)seconds {
dispatch_semaphore_t sem = dispatch_semaphore_create(0);
dispatch_async(queue, ^{
task();
dispatch_semaphore_signal(sem);
});
if (dispatch_semaphore_wait(sem, dispatch_time(DISPATCH_TIME_NOW, (int64_t)(seconds * NSEC_PER_SEC))) != 0)
{
NSLog(@"dispatch timeout! queue:%@", queue);
}
}
在我们定位问题的时候，把sync替换成这个，根据业务不同来设置seconds参数，我们就可以缩小可能造成死锁的位置了，再进一步review代码就八九不离十了。当然这个方法主要用于我们调试的时候更合适，如果是在线上的话，超时时间设置的过小而并没有发生死锁，那么就可能会造成逻辑上的问题了。
