GCD 是libdispath的市場名稱,而libdispath作為Apple的一個庫,為并發(fā)代碼在多核硬件(iOS或者OS X)上執(zhí)行提供有力支持,具有以下的優(yōu)點(diǎn):
1. GCD能通過推遲昂貴的計(jì)算任務(wù)并在后臺運(yùn)行他們來改善你的應(yīng)用的性能
2.GCD提供一個易于使用的并發(fā)模型而不僅僅是鎖和線程,以幫助我們避開并發(fā)陷阱
3.CGD具有在常見設(shè)計(jì)模式(單例)上使用更高性能原語來優(yōu)化你的代碼的潛在能力
并發(fā)(Concurrent)與串發(fā)(Serial)
任務(wù)串發(fā)執(zhí)行指每次只執(zhí)行一次任務(wù),并發(fā)執(zhí)行就是在同一時間可以同時執(zhí)行幾個任務(wù),可以把任務(wù)理解成一個block
同步(Synchronous)與異步(Asynchronous)
一個同步的函數(shù)只能在完成他預(yù)定的任務(wù)后才返回,而一個異步函數(shù)會立即返回,一個異步函數(shù)不會阻塞當(dāng)前線程去執(zhí)行下一個函數(shù)
臨界區(qū) (Critical Section)
一段代碼不能被并發(fā)執(zhí)行,如果兩個并發(fā)線程去同時訪問一個變量,這個變量會變質(zhì)
競態(tài)條件(Race Condition)
具有特定序列和時機(jī)的事件以不受控制的黨法運(yùn)行的行為,競態(tài)條件可能導(dǎo)致無法預(yù)測的行為
死鎖 (Deadlock)
所謂的死鎖是兩個線程卡主了,并等待對方完成操作再執(zhí)行自己,第一個不能完成是等第二個執(zhí)行完成,第二個沒有完成是等第一個執(zhí)行完畢
線程安全 (Thread Safe)
線程安全的代碼能在多線程或并發(fā)任務(wù)中被安全的調(diào)用,而不會導(dǎo)致任何問題(數(shù)據(jù)變質(zhì),損壞,崩潰等);一個線程安全代碼的例子是 NSDictionary 悍缠。你可以在同一時間在多個線程中使用它而不會有問題屈嗤。另一方面冒嫡，NSMutableDictionary 就不是線程安全的驹碍，應(yīng)該保證一次只能有一個線程訪問它。 線程不安全的代碼在某個時刻只能在一個上下文中運(yùn)行
上下文切換(Context Switch)
一個上下文切換是指在你在單個進(jìn)程中切換執(zhí)行不同的線程是存儲和恢復(fù)執(zhí)行狀態(tài)的代碼,這個過程在編寫多任務(wù)的應(yīng)用時很普遍,但會帶來一定的額外開銷
并發(fā)(Concurrency)與并行(Parallelism)
并發(fā)代碼的不同部分可以"同步"執(zhí)行,多核設(shè)備通過并行來同時執(zhí)行多個線程,單核設(shè)備只能也能實(shí)現(xiàn)這一點(diǎn),他們必須先運(yùn)行一個線程,執(zhí)行一個上下文切換,然后再運(yùn)行另外一個線程,這通常發(fā)生的特別快給我們并行執(zhí)行的錯覺,雖然我們編寫代碼在GCD下并發(fā)執(zhí)行,但是GCD會決定有多少并行的需求,并行要求必須是并發(fā), 單是并發(fā)并不能保證并行
隊(duì)列 Queues ?
GCD 提供有 dispatch queues 來處理代碼塊翁垂，這些隊(duì)列管理你提供給 GCD 的任務(wù)并用 FIFO 順序執(zhí)行這些任務(wù)术陶。這就保證了第一個被添加到隊(duì)列里的任務(wù)會是隊(duì)列中第一個開始的任務(wù)缘缚，而第二個被添加的任務(wù)將第二個開始，如此直到隊(duì)列的終點(diǎn),所有的調(diào)度隊(duì)列自身都是線程安全的,你能從多個線程并行的訪問它們.
GCD為我們提供了兩種調(diào)度隊(duì)列
Serial Queues 串行隊(duì)列 ? 這些任務(wù)的執(zhí)行時機(jī)受到GCD的控制,唯一確保的事情是GCD一次只執(zhí)行一個任務(wù),并且按照我們添加到隊(duì)列的順序來執(zhí)行,這樣就不會發(fā)生同時訪問臨界區(qū)的風(fēng)險
Concurrent Queues 并發(fā)隊(duì)列
在并發(fā)隊(duì)列總能保證他們會按照被添加的順序開始執(zhí)行.任務(wù)可能以任何順序完成,也不知道什么時候回開始執(zhí)行下一個任務(wù),或者現(xiàn)在執(zhí)行著幾個任務(wù), 這些都取決于GCD
我們可以創(chuàng)建隊(duì)列,也可以用系統(tǒng)提供給我們的的隊(duì)列(5個)
參考: http://www.cocoachina.com/industry/20140428/8248.html
補(bǔ)充 :?
參考 : http://objccn.io/issue-2-1/
NSThrear 是對pthreat的封裝, 是因?yàn)椴徽撌褂胮thread還是NSThread來直接對線程操作,接使用線程可能會引發(fā)的一個問題是，如果你的代碼和所基于的框架代碼都創(chuàng)建自己的線程時候衍，那么活動的線程數(shù)量有可能以指數(shù)級增長笼蛛。這在大型工程中是一個常見問題。例如蛉鹿，在 8 核 CPU 中伐弹，你創(chuàng)建了 8 個線程來完全發(fā)揮 CPU 性能。然而在這些線程中你的代碼所調(diào)用的框架代碼也做了同樣事情（因?yàn)樗⒉恢滥阋呀?jīng)創(chuàng)建的這些線程）榨为，這樣會很快產(chǎn)生成成百上千的線程惨好。代碼的每個部分自身都沒有問題，然而最后卻還是導(dǎo)致了問題随闺。使用線程并不是沒有代價的日川，每個線程都會消耗一些內(nèi)存和內(nèi)核資源,通過 GCD，開發(fā)者不用再直接跟線程打交道了矩乐，只需要向隊(duì)列中添加代碼塊即可龄句，GCD 在后端管理著一個線程池。GCD 不僅決定著你的代碼塊將在哪個線程被執(zhí)行散罕，它還根據(jù)可用的系統(tǒng)資源對這些線程進(jìn)行管理分歇。這樣可以將開發(fā)者從線程管理的工作中解放出來，通過集中的管理線程欧漱，來緩解大量線程被創(chuàng)建的問題职抡。操作隊(duì)列（operation queue）是由 GCD 提供的一個隊(duì)列模型的 Cocoa 抽象。GCD 提供了更加底層的控制误甚，而操作隊(duì)列則在 GCD 之上實(shí)現(xiàn)了一些方便的功能缚甩，這些功能對于 app 的開發(fā)者來說通常是最好最安全的選擇。
