今天博主有一個(gè)多線程開發(fā)的需求,遇到了一些困難點(diǎn),在此和大家分享,希望能夠共同進(jìn)步.

 在iOS開發(fā)中,多線程開發(fā)是非常重要的核心之一,這篇文章和大家分享一下多線程的進(jìn)階-死鎖.

iOS有三種多線程編程的技術(shù)，分別是：
（一）NSThread
（二）Cocoa NSOperation
（三）GCD（全稱：Grand Central Dispatch）

如果你對(duì)多線程開發(fā)還沒有基本的了解,建議你看下面兩篇博客

http://www.survivalescaperooms.com/kenshincui/p/3983982.html

http://blog.jobbole.com/69019/

這里就不對(duì)基本概念及應(yīng)用做過多的贅述了,用下面五個(gè)案例為大家進(jìn)階多線程開發(fā).

串行與并行

在使用GCD的時(shí)候，我們會(huì)把需要處理的任務(wù)放到Block中，然后將任務(wù)追加到相應(yīng)的隊(duì)列里面，這個(gè)隊(duì)列，叫做Dispatch Queue。然而，存在于兩種Dispatch Queue，一種是要等待上一個(gè)執(zhí)行完，再執(zhí)行下一個(gè)的Serial Dispatch Queue，這叫做串行隊(duì)列；另一種，則是不需要上一個(gè)執(zhí)行完，就能執(zhí)行下一個(gè)的Concurrent Dispatch Queue，叫做并行隊(duì)列。這兩種，均遵循FIFO原則。

舉一個(gè)簡(jiǎn)單的例子，在三個(gè)任務(wù)中輸出1、2、3，串行隊(duì)列輸出是有序的1、2、3，但是并行隊(duì)列的先后順序就不一定了。

那么，并行隊(duì)列又是怎么在執(zhí)行呢？

雖然可以同時(shí)多個(gè)任務(wù)的處理，但是并行隊(duì)列的處理量，還是要根據(jù)當(dāng)前系統(tǒng)狀態(tài)來。如果當(dāng)前系統(tǒng)狀態(tài)最多處理2個(gè)任務(wù)，那么1、2會(huì)排在前面，3什么時(shí)候操作，就看1或者2誰先完成，然后3接在后面。

串行和并行就簡(jiǎn)單說到這里，關(guān)于它們的技術(shù)點(diǎn)其實(shí)還有很多，可以自行了解。

同步與異步

串行與并行針對(duì)的是隊(duì)列，而同步與異步，針對(duì)的則是線程。最大的區(qū)別在于，同步線程要阻塞當(dāng)前線程，必須要等待同步線程中的任務(wù)執(zhí)行完，返回以后，才能繼續(xù)執(zhí)行下一任務(wù)；而異步線程則是不用等待。

僅憑這幾句話還是很難理解，所以之后準(zhǔn)備了很多案例，可以邊分析邊理解。

GCD API

GCD API很多，這里僅介紹本文用到的。

1. 系統(tǒng)標(biāo)準(zhǔn)提供的兩個(gè)隊(duì)列

2. 除此之外，還可以自己生成隊(duì)列

接下來是同步與異步線程的創(chuàng)建：

案例與分析

假設(shè)你已經(jīng)基本了解了上面提到的知識(shí)，接下來進(jìn)入案例講解階段。

案例一：

結(jié)果，控制臺(tái)輸出：

分析：

1. dispatch_sync表示是一個(gè)同步線程；
2. dispatch_get_main_queue表示運(yùn)行在主線程中的主隊(duì)列；
3. 任務(wù)2是同步線程的任務(wù)。

首先執(zhí)行任務(wù)1，這是肯定沒問題的，只是接下來，程序遇到了同步線程，那么它會(huì)進(jìn)入等待，等待任務(wù)2執(zhí)行完，然后執(zhí)行任務(wù)3。但這是隊(duì)列，有任務(wù)來，當(dāng)然會(huì)將任務(wù)加到隊(duì)尾，然后遵循FIFO原則執(zhí)行任務(wù)。那么，現(xiàn)在任務(wù)2就會(huì)被加到最后，任務(wù)3排在了任務(wù)2前面，問題來了：

任務(wù)3要等任務(wù)2執(zhí)行完才能執(zhí)行，任務(wù)2由排在任務(wù)3后面，意味著任務(wù)2要在任務(wù)3執(zhí)行完才能執(zhí)行，所以他們進(jìn)入了互相等待的局面。【既然這樣，那干脆就卡在這里吧】這就是死鎖。

案例二：

結(jié)果，控制臺(tái)輸出：

分析：

首先執(zhí)行任務(wù)1，接下來會(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。

案例三：

結(jié)果，控制臺(tái)輸出：

分析：

這個(gè)案例沒有使用系統(tǒng)提供的串行或并行隊(duì)列，而是自己通過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í)行。這就又陷入了無限的等待中，造成死鎖。

案例四：

結(jié)果，控制臺(tái)輸出：

分析：

首先，將【任務(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中，這時(shí)加入的任務(wù)3在任務(wù)5的后面。

當(dāng)任務(wù)3執(zhí)行完以后，沒有了阻塞，程序繼續(xù)執(zhí)行任務(wù)4。

從以上的分析來看，得到的幾個(gè)結(jié)果：1最先執(zhí)行；2和5順序不一定；4一定在3后面。

案例五：

分析：

和上面幾個(gè)案例的分析類似，先來看看都有哪些任務(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無法執(zhí)行，當(dāng)然任務(wù)3也無法執(zhí)行，在死循環(huán)后的任務(wù)5也不會(huì)執(zhí)行。

最終，只能得到1和4順序不定的結(jié)果。

如果你對(duì)多線程開發(fā)有了一定的了解,相信所有人都會(huì)跟你說GCD是最強(qiáng)大的,但是正如沒有什么東西或者人是完美的,GCD也有它完成不了的工作,如果你正在做下載相關(guān)的開發(fā),也許你會(huì)發(fā)現(xiàn),GCD無法取消任務(wù),你還是要用NSOperationQueue,建議你看下面這篇博客

http://www.jianshu.com/p/fe1fec3d198f?plg_nld=1&utm_source=QQ&utm_content=note&plg_auth=1&utm_campaign=hugo&plg_dev=1&utm_medium=reader_share&plg_nld=1&plg_uin=1&plg_usr=1&plg_vkey=1