这里如果我将22222上面的更改为dispatch_sync(q, ^{ ，请问执行结果是什么？
答案是执行到这里崩溃了，我们来分析一下，为什么这里会崩溃？很多博客上面都有说会崩溃
但是理由很牵强。大概是下面截图这个意思。
老实说，这个说法很牵强。看这段我自己都不能说服我自己，下面是唯一能说服我的帖子，是从源码的角度来说的。
一个曲高和寡语言水平很捉急的大神给出的源码
但是他的分析太难看懂了，主要是因为语文水平很捉急。这里我帮大家总结一下。
实际上GCD里面关于实现同步队列使用到的是信号量，模拟出来大概是这样子的
@synchronized (self) {
if (self.array.count synsc block里面需要被执行的
//一个同步事件可以分为两部分. 第一wait queue, 第二, 派发事件.
//此处为了方便, 两行代码位置是反的. 但是由于async 派遣, 本身就拼到了队列末尾. 所以
//从实际执行角度, 顺序是没有问题的. 完整模拟了. dispatch源码中对事件的执行模式和 同步派遣到本身队列的死锁问题.
dispatch_async(queue, ^{
dispatch_semaphore_signal(semaphore);
});
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
[self.array removeLastObject];
NSLog(@"\n");
NSLog(@"消费了 同步!!!!!!事件");
NSLog(@"\n");
syncEvent = NO;
}else{
//普通消费.
dispatch_async(dispatch_get_global_queue(0, 0), ^{
@synchronized (self) {
[self.array removeLastObject];
NSLog(@"消费了一个异步事件.");
}
});
}
}
想要看懂上面这段代码，你需要反复理解下面几句话，我当时想了一下午才想通。
串行队列里面只可能有一个线程，并行队列里面可能有多个。
队列里面可能没有线程，线程总是跑来跑去的。
不管是同步函数或者是异步函数，都会将block里面的内容派遣到对应的队列的最下面。
同步函数里面维护了一套信号量，信号量的single操作被套在异步函数里面
dispatch_async(queue, ^{
dispatch_semaphore_signal(semaphore);
});
同步函数的的其他操作在同步函数所处的外面的队列里面去执行，只有
dispatch_semaphore_signal(semaphore);
在同步函数锁包裹的队列里面去执行。
综上所述，这行代码将信号量的++事件放到了queue队列的最后。如果同步函数外面没有对queue做派遣动作，不会死锁。
我们将这些理论放到实际例子里面去解释
- (void)viewDidLoad {
[super viewDidLoad];
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"1111");
});
NSLog(@"222");
}
外面是主队列，主队列里面是主线程，同步函数将NSLog(@"1111"); 压倒主队列的底部了。里外都是主队列，事件顺序执行。
同步函数底层按照顺序异步函数将dispatch_semaphore_signal(semaphore);
压在queue（主队列）的最下面
dispatch_async(queue, ^{
dispatch_semaphore_signal(semaphore);
});
然后执行
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
信号量--为-1，阻塞当前线程
，这样程序员永远都执行不到dispatch_semaphore_signal(semaphore)
思考
这个例子不知道大家看懂了没有，是不是感觉这样分析的话，只要使用同步函数都会被死锁。
其实同步函数的底层下面这个函数能够执行到线程就不会被锁住
dispatch_async(queue, ^{
dispatch_semaphore_signal(semaphore);
});
如何能执行dispatch_semaphore_signal(semaphore);
信号量的++操作被压在queue的最下面了，只要同步函数的执行的queue和外面的queue不一致，这里就会被执行了。
看这个例子，我们将同步函数派遣的主队列换成一个新的串行队列
- (void)viewDidLoad {
[super viewDidLoad];
dispatch_sync(dispatch_queue_create("1111", DISPATCH_QUEUE_SERIAL), ^{
NSLog(@"1111");
});
NSLog(@"222");
}
这样同步函数的底层在主队列里面执行下面信号量--
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
主队列里面执行异步函数+串行队列，将信号量++压在串行队列的底部，串行队列唯一事件为信号量++函数，于是执行解锁
dispatch_async(queue, ^{
dispatch_semaphore_signal(semaphore);
});
再来一个例子
dispatch_queue_t q = dispatch_queue_create("1111111", DISPATCH_QUEUE_SERIAL);
dispatch_sync(q, ^{
NSLog(@"11111");
dispatch_sync(q, ^{
NSLog(@"22222");
});
NSLog(@"33333");
});
NSLog(@"44444");
NSLog(@"5555");
第一层同步函数处在主队列里面，
同步函数的底层主队列里面执行
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
在新的串行队列里面执行
dispatch_async(queue, ^{
dispatch_semaphore_signal(semaphore);
});
这两步操作分开在不同的队列里面，都能执行，所以不会死锁
第二层同步函数处在q队列里面
同步函数的底层q串行队列里面执行，锁住了q队列，q队列无法执行其他事件
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
在q串行队列里面执行，被压入队列事件中，但是因为信号量锁住线程gg
dispatch_async(queue, ^{
dispatch_semaphore_signal(semaphore);
});