GCD 是libdispath的市場(chǎng)名稱,而libdispath作為Apple的一個(gè)庫(kù),為并發(fā)代碼在多核硬件(iOS或者OS X)上執(zhí)行提供有力支持,具有以下的優(yōu)點(diǎn):

1. GCD能通過(guò)推遲昂貴的計(jì)算任務(wù)并在后臺(tái)運(yùn)行他們來(lái)改善你的應(yīng)用的性能

2.GCD提供一個(gè)易于使用的并發(fā)模型而不僅僅是鎖和線程,以幫助我們避開并發(fā)陷阱

3.CGD具有在常見設(shè)計(jì)模式(單例)上使用更高性能原語(yǔ)來(lái)優(yōu)化你的代碼的潛在能力

并發(fā)(Concurrent)與串發(fā)(Serial)

任務(wù)串發(fā)執(zhí)行指每次只執(zhí)行一次任務(wù),并發(fā)執(zhí)行就是在同一時(shí)間可以同時(shí)執(zhí)行幾個(gè)任務(wù),可以把任務(wù)理解成一個(gè)block

同步(Synchronous)與異步(Asynchronous)

一個(gè)同步的函數(shù)只能在完成他預(yù)定的任務(wù)后才返回,而一個(gè)異步函數(shù)會(huì)立即返回,一個(gè)異步函數(shù)不會(huì)阻塞當(dāng)前線程去執(zhí)行下一個(gè)函數(shù)

臨界區(qū) (Critical Section)

一段代碼不能被并發(fā)執(zhí)行,如果兩個(gè)并發(fā)線程去同時(shí)訪問(wèn)一個(gè)變量,這個(gè)變量會(huì)變質(zhì)

競(jìng)態(tài)條件(Race Condition)

具有特定序列和時(shí)機(jī)的事件以不受控制的黨法運(yùn)行的行為,競(jìng)態(tài)條件可能導(dǎo)致無(wú)法預(yù)測(cè)的行為

死鎖 (Deadlock)

所謂的死鎖是兩個(gè)線程卡主了,并等待對(duì)方完成操作再執(zhí)行自己,第一個(gè)不能完成是等第二個(gè)執(zhí)行完成,第二個(gè)沒(méi)有完成是等第一個(gè)執(zhí)行完畢

線程安全 (Thread Safe)

線程安全的代碼能在多線程或并發(fā)任務(wù)中被安全的調(diào)用,而不會(huì)導(dǎo)致任何問(wèn)題(數(shù)據(jù)變質(zhì),損壞,崩潰等);一個(gè)線程安全代碼的例子是 NSDictionary 。你可以在同一時(shí)間在多個(gè)線程中使用它而不會(huì)有問(wèn)題。另一方面，NSMutableDictionary 就不是線程安全的，應(yīng)該保證一次只能有一個(gè)線程訪問(wèn)它。 線程不安全的代碼在某個(gè)時(shí)刻只能在一個(gè)上下文中運(yùn)行

上下文切換(Context Switch)

一個(gè)上下文切換是指在你在單個(gè)進(jìn)程中切換執(zhí)行不同的線程是存儲(chǔ)和恢復(fù)執(zhí)行狀態(tài)的代碼,這個(gè)過(guò)程在編寫多任務(wù)的應(yīng)用時(shí)很普遍,但會(huì)帶來(lái)一定的額外開銷

并發(fā)(Concurrency)與并行(Parallelism)

并發(fā)代碼的不同部分可以"同步"執(zhí)行,多核設(shè)備通過(guò)并行來(lái)同時(shí)執(zhí)行多個(gè)線程,單核設(shè)備只能也能實(shí)現(xiàn)這一點(diǎn),他們必須先運(yùn)行一個(gè)線程,執(zhí)行一個(gè)上下文切換,然后再運(yùn)行另外一個(gè)線程,這通常發(fā)生的特別快給我們并行執(zhí)行的錯(cuò)覺(jué),雖然我們編寫代碼在GCD下并發(fā)執(zhí)行,但是GCD會(huì)決定有多少并行的需求,并行要求必須是并發(fā), 單是并發(fā)并不能保證并行

隊(duì)列 Queues ?

GCD 提供有 dispatch queues 來(lái)處理代碼塊，這些隊(duì)列管理你提供給 GCD 的任務(wù)并用 FIFO 順序執(zhí)行這些任務(wù)。這就保證了第一個(gè)被添加到隊(duì)列里的任務(wù)會(huì)是隊(duì)列中第一個(gè)開始的任務(wù)，而第二個(gè)被添加的任務(wù)將第二個(gè)開始，如此直到隊(duì)列的終點(diǎn),所有的調(diào)度隊(duì)列自身都是線程安全的,你能從多個(gè)線程并行的訪問(wèn)它們.

GCD為我們提供了兩種調(diào)度隊(duì)列

Serial Queues 串行隊(duì)列 ? 這些任務(wù)的執(zhí)行時(shí)機(jī)受到GCD的控制,唯一確保的事情是GCD一次只執(zhí)行一個(gè)任務(wù),并且按照我們添加到隊(duì)列的順序來(lái)執(zhí)行,這樣就不會(huì)發(fā)生同時(shí)訪問(wèn)臨界區(qū)的風(fēng)險(xiǎn)

Concurrent Queues 并發(fā)隊(duì)列

在并發(fā)隊(duì)列總能保證他們會(huì)按照被添加的順序開始執(zhí)行.任務(wù)可能以任何順序完成,也不知道什么時(shí)候回開始執(zhí)行下一個(gè)任務(wù),或者現(xiàn)在執(zhí)行著幾個(gè)任務(wù), 這些都取決于GCD

我們可以創(chuàng)建隊(duì)列,也可以用系統(tǒng)提供給我們的的隊(duì)列(5個(gè))

參考: http://www.cocoachina.com/industry/20140428/8248.html

補(bǔ)充 :?

參考 : http://objccn.io/issue-2-1/

NSThrear 是對(duì)pthreat的封裝, 是因?yàn)椴徽撌褂胮thread還是NSThread來(lái)直接對(duì)線程操作,接使用線程可能會(huì)引發(fā)的一個(gè)問(wèn)題是，如果你的代碼和所基于的框架代碼都創(chuàng)建自己的線程時(shí)，那么活動(dòng)的線程數(shù)量有可能以指數(shù)級(jí)增長(zhǎng)。這在大型工程中是一個(gè)常見問(wèn)題。例如，在 8 核 CPU 中，你創(chuàng)建了 8 個(gè)線程來(lái)完全發(fā)揮 CPU 性能。然而在這些線程中你的代碼所調(diào)用的框架代碼也做了同樣事情（因?yàn)樗⒉恢滥阋呀?jīng)創(chuàng)建的這些線程），這樣會(huì)很快產(chǎn)生成成百上千的線程。代碼的每個(gè)部分自身都沒(méi)有問(wèn)題，然而最后卻還是導(dǎo)致了問(wèn)題。使用線程并不是沒(méi)有代價(jià)的，每個(gè)線程都會(huì)消耗一些內(nèi)存和內(nèi)核資源,通過(guò) GCD，開發(fā)者不用再直接跟線程打交道了，只需要向隊(duì)列中添加代碼塊即可，GCD 在后端管理著一個(gè)線程池。GCD 不僅決定著你的代碼塊將在哪個(gè)線程被執(zhí)行，它還根據(jù)可用的系統(tǒng)資源對(duì)這些線程進(jìn)行管理。這樣可以將開發(fā)者從線程管理的工作中解放出來(lái)，通過(guò)集中的管理線程，來(lái)緩解大量線程被創(chuàng)建的問(wèn)題。操作隊(duì)列（operation queue）是由 GCD 提供的一個(gè)隊(duì)列模型的 Cocoa 抽象。GCD 提供了更加底層的控制，而操作隊(duì)列則在 GCD 之上實(shí)現(xiàn)了一些方便的功能，這些功能對(duì)于 app 的開發(fā)者來(lái)說(shuō)通常是最好最安全的選擇。