（1）主隊(duì)列
主隊(duì)列是GCD自帶的一種特殊的串行隊(duì)列，放在主隊(duì)列中得任務(wù)躏尉，都會(huì)放到主線程中執(zhí)行蚯根。
dispatch_get_main_queue()
下面主要研究一下在主隊(duì)列中的同步和異步問(wèn)題：
<1>同步
- (void)viewDidLoad {
[superviewDidLoad];
NSLog(@"%@",[NSThreadcurrentThread]);
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"sync----%@",[NSThreadcurrentThread]);
});
NSLog(@"%@",[NSThreadcurrentThread]);
}
打印結(jié)果：
你可能會(huì)奇怪：為什么只有一條打印記錄？其實(shí)這里出現(xiàn)了死鎖胀糜，所以后面的打印颅拦，包括同步任務(wù)里面的打印都無(wú)法執(zhí)行，為什么會(huì)發(fā)生死鎖呢教藻，關(guān)鍵問(wèn)題出現(xiàn)在設(shè)置的dispatch_sync方法里面的第一個(gè)參數(shù)距帅，下面來(lái)分析一下。
首先括堤，系統(tǒng)執(zhí)行時(shí)碌秸，肯定是從主線程執(zhí)行第一個(gè)打印，之后執(zhí)行到dispatch_sync方法悄窃，這是同步方法讥电，這個(gè)方法第一個(gè)參數(shù)是dispatch_get_main_queue()，所以會(huì)將block的打印任務(wù)放到主隊(duì)列中等待執(zhí)行轧抗。此時(shí)恩敌，主線程阻塞在這，等待同步任務(wù)的執(zhí)行鸦致。但是潮剪，主隊(duì)列串行隊(duì)列，一個(gè)任務(wù)執(zhí)行結(jié)束才能取出下一個(gè)任務(wù)執(zhí)行分唾，而此時(shí)當(dāng)前的任務(wù)被阻塞了抗碰，無(wú)法結(jié)束，所以后一個(gè)任務(wù)（即剛剛添加的同步任務(wù)）必須等待前一個(gè)任務(wù)結(jié)束后才能執(zhí)行绽乔。此時(shí)弧蝇，主線程等待著同步任務(wù)執(zhí)行結(jié)束返回，而同步任務(wù)等待著主隊(duì)列的前一個(gè)任務(wù)（即當(dāng)前被阻塞的任務(wù)）執(zhí)行結(jié)束后再執(zhí)行。所以出現(xiàn)了死鎖的現(xiàn)象看疗。我們應(yīng)該盡量避免這種情況的發(fā)生沙峻。那么如果換成dispatch_async方法，是否就不會(huì)出現(xiàn)死鎖了呢两芳？
<2>異步
- (void)viewDidLoad {
[superviewDidLoad];
NSLog(@"%@",[NSThreadcurrentThread]);
dispatch_async(dispatch_get_main_queue(), ^{
NSLog(@"async----%@",[NSThreadcurrentThread]);
});
NSLog(@"%@",[NSThreadcurrentThread]);
}
打印結(jié)果：
顯然摔寨，這種情況下，所有的打印都能完成怖辆，簡(jiǎn)單分析一下：主線程首先執(zhí)行第一個(gè)打印是复，執(zhí)行到dispatch_async方法時(shí)，往主隊(duì)列添加了一個(gè)異步任務(wù)竖螃，此時(shí)并不阻塞主線程淑廊，主線程立刻返回執(zhí)行后面的打印。主線程當(dāng)前的任務(wù)完成了特咆，然后從主隊(duì)列取出下一個(gè)任務(wù)（剛剛添加的異步任務(wù)）來(lái)執(zhí)行季惩，完成打印async—-。所以不會(huì)出現(xiàn)死鎖現(xiàn)象腻格。
（2）全局隊(duì)列
dispatch_get_global_queue(longidentifier,unsignedlongflags)
第一個(gè)參數(shù)identifier: 在ios7中代表隊(duì)列優(yōu)先級(jí)（priority）画拾，在ios8及以后代表服務(wù)質(zhì)量（A quality of service），一般設(shè)置為DISPATCH_QUEUE_PRIORITY_DEFAULT即可荒叶。
兩者的對(duì)應(yīng)關(guān)系如下：
DISPATCH_QUEUE_PRIORITY_HIGH: QOS_CLASS_USER_INITIATED
DISPATCH_QUEUE_PRIORITY_DEFAULT: QOS_CLASS_DEFAULT
DISPATCH_QUEUE_PRIORITY_LOW: QOS_CLASS_UTILITY
DISPATCH_QUEUE_PRIORITY_BACKGROUND: QOS_CLASS_BACKGROUND
第二個(gè)參數(shù)flags:保留參數(shù)碾阁，以便以后使用，一般傳0即可些楣。
在全局隊(duì)列中脂凶，同步任務(wù)是否也會(huì)發(fā)生死鎖現(xiàn)象呢？
<1>同步
- (void)viewDidLoad {
[superviewDidLoad];
NSLog(@"%@",[NSThreadcurrentThread]);
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
NSLog(@"sync----%@",[NSThreadcurrentThread]);
});
NSLog(@"%@",[NSThreadcurrentThread]);
}
打印結(jié)果：
從打印結(jié)果來(lái)看愁茁，并沒(méi)有死鎖現(xiàn)象蚕钦，仔細(xì)分析一下：主線程先執(zhí)行第一句打印，然后執(zhí)行dispatch_sync方法鹅很，往全局隊(duì)列中添加一個(gè)同步任務(wù)嘶居，此時(shí)主線程應(yīng)該阻塞住，等待全局隊(duì)列中同步任務(wù)的執(zhí)行完畢促煮，而全局隊(duì)列dispatch_sync方法并不會(huì)創(chuàng)建新線程邮屁，那肯定需要在主線程執(zhí)行（上一篇的結(jié)論），可是主線程已經(jīng)阻塞了菠齿，所以按理說(shuō)此時(shí)應(yīng)該發(fā)生死鎖佑吝，可是為什么從打印結(jié)果看它確實(shí)是在主線程執(zhí)行的同步任務(wù)，而且并沒(méi)有發(fā)生死鎖現(xiàn)象呢绳匀？
對(duì)應(yīng)這個(gè)問(wèn)題芋忿，我利用前面和上面的知識(shí)都無(wú)法解釋?zhuān)以诰W(wǎng)上查了很多炸客，都沒(méi)有提到過(guò)這個(gè)問(wèn)題，難道是我上面的分析有問(wèn)題戈钢，按照上面的分析痹仙，那所有的同步方法，無(wú)論是自定義隊(duì)列還是全局隊(duì)列殉了、主隊(duì)列开仰，同步任務(wù)都會(huì)出現(xiàn)死鎖現(xiàn)象。難道我鉆了牛角尖宣渗。沒(méi)有找到中文的解釋?zhuān)胰ス俜轿臋n是查抖所，也一無(wú)所獲，最后我無(wú)意的點(diǎn)進(jìn)了dispatch_sync的源代碼中痕囱，在該方法上面的注釋中發(fā)現(xiàn)了這么一句話：As an optimization, dispatch_sync() invokes the block on the current thread when possible.大致意思是：蘋(píng)果系統(tǒng)內(nèi)部做了優(yōu)化，將所有的dispatch_sync()方法中block的執(zhí)行都放在當(dāng)前的線程中暴匠，在我們這里也就是主線程中鞍恢。這也解釋了上一篇留下的一個(gè)問(wèn)題：為什么所有的同步方法都在主線程中執(zhí)行 ？可是每窖，這個(gè)解釋?zhuān)孟癫⒉荒芑卮馂槭裁催@里沒(méi)有發(fā)生死鎖的問(wèn)題帮掉？我也一直沒(méi)有找到合理的解釋?zhuān)绻奈挥斜容^合理的解釋?zhuān)闊┙o我留言。
我個(gè)人的猜測(cè)：是否會(huì)在需要執(zhí)行dispatch_sync()方法時(shí)窒典，將當(dāng)前任務(wù)先掛起蟆炊，只要能取出要執(zhí)行的任務(wù)來(lái)就讓主線程先執(zhí)行，之后再來(lái)執(zhí)行掛起任務(wù)瀑志。這個(gè)猜測(cè)似乎和主隊(duì)列同步方法發(fā)生死鎖的解釋不矛盾涩搓，主隊(duì)列中的任務(wù)只能前一個(gè)執(zhí)行完后一個(gè)才能取出來(lái)執(zhí)行，所以在主隊(duì)列中后面的同步任務(wù)無(wú)法取出來(lái)劈猪，自然會(huì)發(fā)生死鎖昧甘。而全局隊(duì)列中，同步任務(wù)就是最前面的任務(wù)战得，所以能取出來(lái)充边，所以可以由主線程來(lái)執(zhí)行，執(zhí)行后主線程可以返回執(zhí)行后面的操作常侦。
轉(zhuǎn)載自feisongfs
