GCD提供了功能強(qiáng)大的任務(wù)和隊(duì)列控制功能，相比于NSOperationQueue更加底層，因此如果不注意也會(huì)導(dǎo)致死鎖。
1.什么是GCD死鎖 ?
所謂死鎖，通常指有兩個(gè)線程A和B都卡住了，A在等B ,B在等A,相互等待對(duì)方完成某些操作。A不能完成是因?yàn)樗诘却鼴完成。但B也不能完成，因?yàn)樗诘却鼳完成。于是大家都完不成，就導(dǎo)致了死鎖（DeadLock）。
對(duì)于部分新手來(lái)說(shuō), 可能認(rèn)為GCD死鎖是很高端的操作系統(tǒng)層面的問(wèn)題，離我很遠(yuǎn)，一般不會(huì)遇上。其實(shí)這種想法是非常錯(cuò)誤的，因?yàn)橹灰?jiǎn)單三行代碼（如果愿意，甚至寫在一行就可以）就可以人為創(chuàng)造出死鎖的情況,如:
int main(int argc, const char * argv[]) {
@autoreleasepool {
dispatch_sync(dispatch_get_main_queue(), ^(void){
NSLog(@"這里死鎖了");
});
}
return 0;
}
2. 要理解GCD死鎖,必須先理解GCD的幾個(gè)概念:
2.1串行與并行
串行和并行都是相對(duì)于隊(duì)列而言的
隊(duì)列（負(fù)責(zé)調(diào)度任務(wù)）
串行隊(duì)列：一個(gè)接一個(gè)的調(diào)度任務(wù)
并發(fā)隊(duì)列：可以同時(shí)調(diào)度多個(gè)任務(wù)
在使用GCD的時(shí)候，我們會(huì)把需要處理的任務(wù)放到Block中，然后將任務(wù)追加到相應(yīng)的隊(duì)列里面，這個(gè)隊(duì)列，叫做Dispatch Queue。
隊(duì)列一般存在于兩種Dispatch Queue，
一種是要等待上一個(gè)執(zhí)行完，再執(zhí)行下一個(gè)的Serial Dispatch Queue，這叫做串行隊(duì)列；
另一種，則是不需要上一個(gè)執(zhí)行完，就能執(zhí)行下一個(gè)的Concurrent Dispatch Queue，叫做并行隊(duì)列。
這兩種，均遵循FIFO原則,也就是先進(jìn)先出原則。
舉一個(gè)簡(jiǎn)單的例子，在三個(gè)任務(wù)中輸出1、2、3，
串行隊(duì)列輸出是有序的1、2、3，
但是并行隊(duì)列的先后順序就不一定了。
那么，并行隊(duì)列又是怎么在執(zhí)行呢？
并行隊(duì)列雖然可以同時(shí)多個(gè)任務(wù)的處理，但是并行隊(duì)列的處理量，還是要根據(jù)當(dāng)前系統(tǒng)狀態(tài)來(lái)。如果當(dāng)前系統(tǒng)狀態(tài)最多處理2個(gè)任務(wù)，那么1、2會(huì)排在前面，3什么時(shí)候操作，就看1或者2誰(shuí)先完成，然后3接在后面。
串行和并行就簡(jiǎn)單說(shuō)到這里，關(guān)于它們的技術(shù)點(diǎn)其實(shí)還有很多，可以自行了解。
2.2 同步與異步
串行與并行針對(duì)的是隊(duì)列，而同步與異步，針對(duì)的則是線程。
最大的區(qū)別在于，同步線程要阻塞當(dāng)前線程，必須要等待同步線程中的任務(wù)執(zhí)行完，返回以后，才能繼續(xù)執(zhí)行下一任務(wù)；而異步線程則是不用等待。
僅憑這幾句話還是很難理解，所以可以多準(zhǔn)備幾個(gè)案例，邊分析邊理解。
2.3 GCD API
GCD API很多，這里僅介紹本文用到的。
- 系統(tǒng)標(biāo)準(zhǔn)提供的兩個(gè)隊(duì)列
// 全局隊(duì)列，一個(gè)特殊的并行隊(duì)列
dispatch_get_global_queue
// 主隊(duì)列，在主線程中運(yùn)行，因?yàn)橹骶€程只有一個(gè)，所以這是一個(gè)特殊的串行隊(duì)列
dispatch_get_main_queue
- 除此之外，還可以自己生成隊(duì)列
// 從DISPATCH_QUEUE_SERIAL看出，這是串行隊(duì)列
dispatch_queue_create("com.demo.serialQueue", DISPATCH_QUEUE_SERIAL)
// 同理，這是一個(gè)并行隊(duì)列
dispatch_queue_create("com.demo.concurrentQueue", DISPATCH_QUEUE_CONCURRENT)
- 同步與異步線程的創(chuàng)建：
dispatch_sync(..., ^(block)) // 同步線程
dispatch_async(..., ^(block)) // 異步線程
3.案例與分析
假設(shè)你已經(jīng)基本了解了上面提到的知識(shí)，接下來(lái)進(jìn)入案例講解階段。
案例一： 當(dāng)同步遇到了串行
NSLog(@"1"); // 任務(wù)1
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"2"); // 任務(wù)2
});
NSLog(@"3"); // 任務(wù)3
NSLog(@"3"); // 任務(wù)3
控制臺(tái)輸出結(jié)果:
1
分析：
dispatch_sync表示是一個(gè)同步線程；
dispatch_get_main_queue表示運(yùn)行在主線程中的主隊(duì)列；
任務(wù)2是同步線程的任務(wù)。
任務(wù)3需要等待任務(wù)2結(jié)束之后再執(zhí)行.
首先執(zhí)行任務(wù)1，這是肯定沒(méi)問(wèn)題的，只是接下來(lái)，程序遇到了同步線程，那么它會(huì)進(jìn)入等待，等待任務(wù)2執(zhí)行完，然后執(zhí)行任務(wù)3。但這是主隊(duì)列，是一個(gè)特殊的串行隊(duì)列,有任務(wù)來(lái)，當(dāng)然會(huì)將任務(wù)加到隊(duì)尾，然后遵循FIFO原則執(zhí)行任務(wù)。那么，現(xiàn)在任務(wù)2就會(huì)被加到最后，任務(wù)3排在了任務(wù)2前面，問(wèn)題來(lái)了：
任務(wù)3要等任務(wù)2執(zhí)行完才能執(zhí)行，任務(wù)2又排在任務(wù)3后面，意味著任務(wù)2要在任務(wù)3執(zhí)行完才能執(zhí)行，所以他們進(jìn)入了互相等待的局面?！炯热贿@樣，那干脆就卡在這里吧】這就是死鎖。
案例二：當(dāng)同步遇到了并行
NSLog(@"1"); // 任務(wù)1
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
NSLog(@"2"); // 任務(wù)2
});
NSLog(@"3"); // 任務(wù)3
控制臺(tái)輸出結(jié)果為:
1
2
3
分析：
首先執(zhí)行任務(wù)1，接下來(lái)會(huì)遇到一個(gè)同步線程，程序會(huì)進(jìn)入等待。等待任務(wù)2執(zhí)行完成以后，才能繼續(xù)執(zhí)行任務(wù)3。從dispatch_get_global_queue可以看出，任務(wù)2被加入到了全局的并行隊(duì)列中，當(dāng)并行隊(duì)列執(zhí)行完任務(wù)2以后，返回到主隊(duì)列，繼續(xù)執(zhí)行任務(wù)3。
案例三： 咱們來(lái)點(diǎn)復(fù)雜一些的: 同步異步都有
dispatch_queue_t queue = dispatch_queue_create("com.demo.serialQueue", DISPATCH_QUEUE_SERIAL);
NSLog(@"1"); // 任務(wù)1
dispatch_async(queue, ^{
NSLog(@"2"); // 任務(wù)2
dispatch_sync(queue, ^{
NSLog(@"3"); // 任務(wù)3
});
NSLog(@"4"); // 任務(wù)4
});
NSLog(@"5"); // 任務(wù)5
控制臺(tái)輸出結(jié)果:
1
5
2
// 2 和 5 的順序不一定 , 3, 4, 沒(méi)有輸出
分析：
這個(gè)案例沒(méi)有使用系統(tǒng)提供的串行或并行隊(duì)列，而是自己通過(guò)dispatch_queue_create函數(shù)創(chuàng)建了一個(gè)DISPATCH_QUEUE_SERIAL的串行隊(duì)列。
1.執(zhí)行任務(wù)1；
2.遇到異步線程，將【任務(wù)2、同步線程、任務(wù)4】加入串行隊(duì)列中。因?yàn)槭钱惒骄€程，所以在主線程中的任務(wù)5不必等待異步線程中的所有任務(wù)完成；
3.因?yàn)槿蝿?wù)5不必等待，所以2和5的輸出順序不能確定；
4.任務(wù)2執(zhí)行完以后，遇到同步線程，這時(shí)，將任務(wù)3加入串行隊(duì)列；
5.又因?yàn)槿蝿?wù)4比任務(wù)3早加入串行隊(duì)列，所以，任務(wù)3要等待任務(wù)4完成以后，才能執(zhí)行。但是任務(wù)3所在的同步線程會(huì)阻塞，所以任務(wù)4必須等任務(wù)3執(zhí)行完以后再執(zhí)行。這就又陷入了無(wú)限的等待中，造成死鎖。
案例四：異步遇到同步回主線程
NSLog(@"1"); // 任務(wù)1
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"2"); // 任務(wù)2
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"3"); // 任務(wù)3
});
NSLog(@"4"); // 任務(wù)4
});
NSLog(@"5"); // 任務(wù)5
控制臺(tái)輸出結(jié)果:
1
2
5
3
4
// 2 和 5 順序不一定
分析：
這個(gè)案例,我相信大家都熟悉,沒(méi)錯(cuò),這就是典型的異步加載數(shù)據(jù),回調(diào)主線程更新UI那個(gè)案例;
首先，將【任務(wù)1、異步線程、任務(wù)5】加入Main Queue中，異步線程中的任務(wù)是：【任務(wù)2、同步線程、任務(wù)4】。
所以，先執(zhí)行任務(wù)1，然后將異步線程中的任務(wù)加入到Global Queue中，因?yàn)楫惒骄€程，所以任務(wù)5不用等待，結(jié)果就是2和5的輸出順序不一定。
然后再看異步線程中的任務(wù)執(zhí)行順序。任務(wù)2執(zhí)行完以后，遇到同步線程。將同步線程中的任務(wù)又回調(diào)加入到Main Queue中，這時(shí)加入的任務(wù)3在任務(wù)5的后面。
當(dāng)任務(wù)3執(zhí)行完以后，沒(méi)有了阻塞，程序繼續(xù)執(zhí)行任務(wù)4。
從以上的分析來(lái)看，得到的幾個(gè)結(jié)果：1最先執(zhí)行；2和5順序不一定；4一定在3后面。
案例五： 當(dāng)我們典型案例4,遇到了主線程上出現(xiàn)無(wú)限循環(huán)的時(shí)候
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"1"); // 任務(wù)1
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"2"); // 任務(wù)2
});
NSLog(@"3"); // 任務(wù)3
});
NSLog(@"4"); // 任務(wù)4
while (1) {
}
NSLog(@"5"); // 任務(wù)5
打印臺(tái)輸出結(jié)果:
1
4
// 1 和 4 順序不一定
分析：
和上面幾個(gè)案例的分析類似，先來(lái)看看都有哪些任務(wù)加入了Main Queue：【異步線程、任務(wù)4、死循環(huán)、任務(wù)5】。
在加入到Global Queue異步線程中的任務(wù)有：【任務(wù)1、同步線程、任務(wù)3】。
第一個(gè)就是異步線程，任務(wù)4不用等待，所以結(jié)果任務(wù)1和任務(wù)4順序不一定。
任務(wù)4完成后，程序進(jìn)入死循環(huán)，Main Queue阻塞。但是加入到Global Queue的異步線程不受影響，繼續(xù)執(zhí)行任務(wù)1后面的同步線程。
同步線程中，將任務(wù)2加入到了主線程，并且，任務(wù)3等待任務(wù)2完成以后才能執(zhí)行。這時(shí)的主線程，已經(jīng)被死循環(huán)阻塞了。所以任務(wù)2無(wú)法執(zhí)行，當(dāng)然任務(wù)3也無(wú)法執(zhí)行，在死循環(huán)后的任務(wù)5也不會(huì)執(zhí)行。
最終，只能得到1和4順序不定的結(jié)果。
GCD死鎖問(wèn)題,我們就暫時(shí)討論到這里,上面列舉的5各案例,基本已經(jīng)概括了GCD遇到的絕大多數(shù)情況了,以后有遇到其他情況的時(shí)候,再來(lái)補(bǔ)充。
