串行與并行
在使用GCD的時候，我們會把需要處理的任務(wù)放到Block中伙判，然后將任務(wù)追加到相應(yīng)的隊(duì)列里面，這個隊(duì)列黑忱，叫做Dispatch Queue澳腹。然而，存在于兩種Dispatch Queue杨何，一種是要等待上一個執(zhí)行完，再執(zhí)行下一個的Serial Dispatch Queue沥邻，這叫做串行隊(duì)列危虱；另一種，則是不需要上一個執(zhí)行完唐全，就能執(zhí)行下一個的Concurrent Dispatch Queue埃跷，叫做并行隊(duì)列。這兩種邮利，均遵循FIFO(先進(jìn)先出)原則弥雹。
舉一個簡單的例子，在三個任務(wù)中輸出1延届、2剪勿、3，串行隊(duì)列輸出是有序的1方庭、2厕吉、3酱固，但是并行隊(duì)列的先后順序就不一定了。
那么头朱，并行隊(duì)列又是怎么在執(zhí)行呢运悲？
雖然可以同時多個任務(wù)的處理，但是并行隊(duì)列的處理量项钮，還是要根據(jù)當(dāng)前系統(tǒng)狀態(tài)來班眯。如果當(dāng)前系統(tǒng)狀態(tài)最多處理2個任務(wù)，那么1烁巫、2會排在前面署隘，3什么時候操作，就看1或者2誰先完成程拭，然后3接在后面定踱。
同步與異步
串行與并行針對的是隊(duì)列，而同步與異步恃鞋，針對的則是線程崖媚。最大的區(qū)別在于，同步線程要阻塞當(dāng)前線程恤浪，必須要等待同步線程中的任務(wù)執(zhí)行完畅哑，返回以后，才能繼續(xù)執(zhí)行下一任務(wù)水由，整個過程是不會創(chuàng)建新線程的荠呐；而異步線程則是不用等待，會在新開啟的線程中執(zhí)行任務(wù)(執(zhí)行主隊(duì)列的任務(wù)除外砂客，主隊(duì)列的任務(wù)在主線程中執(zhí)行)泥张。
通過案例明白GCD的執(zhí)行原理
案例一：
NSLog(@"1"); // 任務(wù)1
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"2"); // 任務(wù)2
});
NSLog(@"3"); // 任務(wù)3
輸出結(jié)果：
1
分析：
首先執(zhí)行任務(wù)1，這是肯定沒問題的鞠值，只是接下來媚创，程序遇到了同步線程，那么它會進(jìn)入等待彤恶，等待任務(wù)2執(zhí)行完钞钙，然后執(zhí)行任務(wù)3。但這是隊(duì)列声离，有任務(wù)來芒炼，當(dāng)然會將任務(wù)加到隊(duì)尾，然后遵循FIFO原則執(zhí)行任務(wù)术徊。那么本刽，現(xiàn)在任務(wù)2就會被加到最后，任務(wù)3排在了任務(wù)2前面，問題來了：
任務(wù)3要等任務(wù)2執(zhí)行完才能執(zhí)行盅安，任務(wù)2又排在任務(wù)3后面唤锉，意味著任務(wù)2要在任務(wù)3執(zhí)行完才能執(zhí)行，所以他們進(jìn)入了互相等待的局面别瞭×椋【既然這樣，那干脆就卡在這里吧】這就是死鎖蝙寨。
案例二：
NSLog(@"1"); // 任務(wù)1
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
NSLog(@"2"); // 任務(wù)2
});
NSLog(@"3"); // 任務(wù)3
輸出結(jié)果：
1
2
3
分析：
首先執(zhí)行任務(wù)1晒衩，接下來會遇到一個同步線程，程序會進(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浪漠。
案例三：
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(會在主線程中執(zhí)行)
輸出結(jié)果：
1
5
2
// 5和2的順序不一定
分析：
這個案例沒有使用系統(tǒng)提供的串行或并行隊(duì)列，而是自己通過dispatch_queue_create函數(shù)創(chuàng)建了一個DISPATCH_QUEUE_SERIAL的串行隊(duì)列霎褐。執(zhí)行任務(wù)1址愿；遇到異步線程，將【任務(wù)2冻璃、同步線程响谓、任務(wù)4】加入串行隊(duì)列中。因?yàn)槭钱惒骄€程省艳，所以在主線程中的任務(wù)5不必等待異步線程中的所有任務(wù)完成娘纷；因?yàn)槿蝿?wù)5不必等待，所以2和5的輸出順序不能確定跋炕；任務(wù)2執(zhí)行完以后失驶，遇到同步線程，這時枣购，將任務(wù)3加入串行隊(duì)列；又因?yàn)槿蝿?wù)4比任務(wù)3早加入串行隊(duì)列擦耀，所以棉圈，任務(wù)3要等待任務(wù)4完成以后，才能執(zhí)行眷蜓。但是任務(wù)3所在的同步線程會阻塞分瘾，所以任務(wù)4必須等任務(wù)3執(zhí)行完以后再執(zhí)行。這就又陷入了無限的等待中吁系，造成死鎖德召。
案例四：
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
輸出結(jié)果：
1
2
5
3
4
// 5和2的順序不一定
分析：
首先白魂，將【任務(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ù)加入到Main Queue中，這時加入的任務(wù)3在任務(wù)5的后面薯定。當(dāng)任務(wù)3執(zhí)行完以后始绍，沒有了阻塞，程序繼續(xù)執(zhí)行任務(wù)4话侄。
案例五
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
輸出結(jié)果：
1
4
// 1和4的順序不一定
分析：
和上面幾個案例的分析類似亏推，先來看看都有哪些任務(wù)加入了Main Queue：【異步線程、任務(wù)4年堆、死循環(huán)吞杭、任務(wù)5】。在加入到Global Queue異步線程中的任務(wù)有：【任務(wù)1变丧、同步線程芽狗、任務(wù)3】。第一個就是異步線程痒蓬，任務(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í)行双揪。這時的主線程，已經(jīng)被死循環(huán)阻塞了包帚。所以任務(wù)2無法執(zhí)行渔期，當(dāng)然任務(wù)3也無法執(zhí)行，在死循環(huán)后的任務(wù)5也不會執(zhí)行婴噩。
在網(wǎng)上查閱了很多相關(guān)質(zhì)料擎场，一直對GCD執(zhí)行原理有點(diǎn)模糊，直到看到下面這篇文章醍醐灌頂几莽，感謝這篇文章的作者迅办，本文大部分內(nèi)容摘自其中，本文的主要目的也是為了幫助自己熟悉知識點(diǎn)及以后回顧章蚣，沒有任何其它意圖
http://www.superqq.com/blog/2015/10/16/five-case-know-gcd/
