雖然 GCD 已經(jīng)出現(xiàn)過一段時(shí)間了，但不是每個(gè)人都明了其主要內(nèi)容。這是可以理解的；并發(fā)一直很棘手，而 GCD 是基于 C 的 API ，它們就像一組尖銳的棱角戳進(jìn) Objective-C 的平滑世界。我們將分兩個(gè)部分的教程來深入學(xué)習(xí) GCD 。
在這兩部分的系列中，第一個(gè)部分的將解釋 GCD 是做什么的，并從許多基本的 GCD 函數(shù)中找出幾個(gè)來展示。在第二部分，你將學(xué)到幾個(gè) GCD 提供的高級(jí)函數(shù)。
什么是 GCD
GCD 是 libdispatch 的市場(chǎng)名稱，而 libdispatch 作為 Apple 的一個(gè)庫，為并發(fā)代碼在多核硬件（跑 iOS 或 OS X ）上執(zhí)行提供有力支持。它具有以下優(yōu)點(diǎn)：
1.GCD 能通過推遲昂貴計(jì)算任務(wù)并在后臺(tái)運(yùn)行它們來改善你的應(yīng)用的響應(yīng)性能。
2.GCD 提供一個(gè)易于使用的并發(fā)模型而不僅僅只是鎖和線程，以幫助我們避開并發(fā)陷阱。
3.GCD 具有在常見模式（例如單例）上用更高性能的原語優(yōu)化你的代碼的潛在能力。
本教程假設(shè)你對(duì) Block 和 GCD 有基礎(chǔ)了解。如果你對(duì) GCD 完全陌生，先看看iOS 上的多線程和 GCD 入門教程學(xué)習(xí)其要領(lǐng)。
GCD 術(shù)語
要理解 GCD ，你要先熟悉與線程和并發(fā)相關(guān)的幾個(gè)概念。這兩者都可能模糊和微妙，所以在開始 GCD 之前先簡(jiǎn)要地回顧一下它們。
Serial vs. Concurrent 串行 vs. 并發(fā)
這些術(shù)語描述當(dāng)任務(wù)相對(duì)于其它任務(wù)被執(zhí)行，任務(wù)串行執(zhí)行就是每次只有一個(gè)任務(wù)被執(zhí)行，任務(wù)并發(fā)執(zhí)行就是在同一時(shí)間可以有多個(gè)任務(wù)被執(zhí)行。
雖然這些術(shù)語被廣泛使用，本教程中你可以將任務(wù)設(shè)定為一個(gè) Objective-C 的 Block 。不明白什么是 Block ？看看iOS 5 教程中的如何使用 Block。實(shí)際上，你也可以在 GCD 上使用函數(shù)指針，但在大多數(shù)場(chǎng)景中，這實(shí)際上更難于使用。Block 就是更加容易些！
Synchronous vs. Asynchronous 同步 vs. 異步
在 GCD 中，這些術(shù)語描述當(dāng)一個(gè)函數(shù)相對(duì)于另一個(gè)任務(wù)完成，此任務(wù)是該函數(shù)要求 GCD 執(zhí)行的。一個(gè)同步函數(shù)只在完成了它預(yù)定的任務(wù)后才返回。
一個(gè)異步函數(shù)，剛好相反，會(huì)立即返回，預(yù)定的任務(wù)會(huì)完成但不會(huì)等它完成。因此，一個(gè)異步函數(shù)不會(huì)阻塞當(dāng)前線程去執(zhí)行下一個(gè)函數(shù)。
注意——當(dāng)你讀到同步函數(shù)“阻塞（Block）”當(dāng)前線程，或函數(shù)是一個(gè)“阻塞”函數(shù)或阻塞操作時(shí)，不要被搞糊涂了！動(dòng)詞“阻塞”描述了函數(shù)如 何影響它所在的線程而與名詞“代碼塊（Block）”沒有關(guān)系。代碼塊描述了用 Objective-C 編寫的一個(gè)匿名函數(shù)，它能定義一個(gè)任務(wù)并被提交到 GCD 。
譯者注：中文不會(huì)有這個(gè)問題，“阻塞”和“代碼塊”是兩個(gè)詞。
Critical Section 臨界區(qū)
就是一段代碼不能被并發(fā)執(zhí)行，也就是，兩個(gè)線程不能同時(shí)執(zhí)行這段代碼。這很常見，因?yàn)榇a去操作一個(gè)共享資源，例如一個(gè)變量若能被并發(fā)進(jìn)程訪問，那么它很可能會(huì)變質(zhì)（譯者注：它的值不再可信）。
Race Condition 競(jìng)態(tài)條件
這種狀況是指基于特定序列或時(shí)機(jī)的事件的軟件系統(tǒng)以不受控制的方式運(yùn)行的行為，例如程序的并發(fā)任務(wù)執(zhí)行的確切順序。競(jìng)態(tài)條件可導(dǎo)致無法預(yù)測(cè)的行為，而不能通過代碼檢查立即發(fā)現(xiàn)。
Deadlock 死鎖
兩個(gè)（有時(shí)更多）東西（在大多數(shù)情況下是線程）——所謂的死鎖是指它們都卡住了，并等待對(duì)方完成或執(zhí)行其它操作。第一個(gè)不能完成是因?yàn)樗诘却诙€(gè)的完成。但第二個(gè)也不能完成，因?yàn)樗诘却谝粋€(gè)的完成。
Thread Safe 線程安全
線程安全的代碼能在多線程或并發(fā)任務(wù)中被安全的調(diào)用，而不會(huì)導(dǎo)致任何問題（數(shù)據(jù)損壞，崩潰，等）。線程不安全的代碼在某個(gè)時(shí)刻只能在一個(gè)上下文 中運(yùn)行。一個(gè)線程安全代碼的例子是 NSDictionary 。你可以在同一時(shí)間在多個(gè)線程中使用它而不會(huì)有問題。另一方面，NSMutableDictionary 就不是線程安全的，應(yīng)該保證一次只能有一個(gè)線程訪問它。
Context Switch 上下文切換
一個(gè)上下文切換指當(dāng)你在單個(gè)進(jìn)程里切換執(zhí)行不同的線程時(shí)存儲(chǔ)與恢復(fù)執(zhí)行狀態(tài)的過程。這個(gè)過程在編寫多任務(wù)應(yīng)用時(shí)很普遍，但會(huì)帶來一些額外的開銷。
Concurrency vs Parallelism 并發(fā)與并行
并發(fā)和并行通常被一起提到，所以值得花些時(shí)間解釋它們之間的區(qū)別。
并發(fā)代碼的不同部分可以“同步”執(zhí)行。然而，該怎樣發(fā)生或是否發(fā)生都取決于系統(tǒng)。多核設(shè)備通過并行來同時(shí)執(zhí)行多個(gè)線程；然而，為了使單核設(shè)備也 能實(shí)現(xiàn)這一點(diǎn)，它們必須先運(yùn)行一個(gè)線程，執(zhí)行一個(gè)上下文切換，然后運(yùn)行另一個(gè)線程或進(jìn)程。這通常發(fā)生地足夠快以致給我們并發(fā)執(zhí)行地錯(cuò)覺，如下圖所示：
雖然你可以編寫代碼在 GCD 下并發(fā)執(zhí)行，但 GCD 會(huì)決定有多少并行的需求。并行要求并發(fā)，但并發(fā)并不能保證并行。
更深入的觀點(diǎn)是并發(fā)實(shí)際上是關(guān)于構(gòu)造。當(dāng)你在腦海中用 GCD 編寫代碼，你組織你的代碼來暴露能同時(shí)運(yùn)行的多個(gè)工作片段，以及不能同時(shí)運(yùn)行的那些。如果你想深入此主題，看看this excellent talk by Rob Pike。
Queues 隊(duì)列
GCD 提供有 dispatch queues 來處理代碼塊，這些隊(duì)列管理你提供給 GCD 的任務(wù)并用 FIFO 順序執(zhí)行這些任務(wù)。這就保證了第一個(gè)被添加到隊(duì)列里的任務(wù)會(huì)是隊(duì)列中第一個(gè)開始的任務(wù)，而第二個(gè)被添加的任務(wù)將第二個(gè)開始，如此直到隊(duì)列的終點(diǎn)。
所有的調(diào)度隊(duì)列（dispatch queues）自身都是線程安全的，你能從多個(gè)線程并行的訪問它們。GCD 的優(yōu)點(diǎn)是顯而易見的，即當(dāng)你了解了調(diào)度隊(duì)列如何為你自己代碼的不同部分提供線程安全。關(guān)于這一點(diǎn)的關(guān)鍵是選擇正確類型的調(diào)度隊(duì)列和正確的調(diào)度函數(shù)來提交你 的工作。
在本節(jié)你會(huì)看到兩種調(diào)度隊(duì)列，都是由 GCD 提供的，然后看一些描述如何用調(diào)度函數(shù)添加工作到隊(duì)列的列子。
Serial Queues 串行隊(duì)列
這些任務(wù)的執(zhí)行時(shí)機(jī)受到 GCD 的控制；唯一能確保的事情是 GCD 一次只執(zhí)行一個(gè)任務(wù)，并且按照我們添加到隊(duì)列的順序來執(zhí)行。
由于在串行隊(duì)列中不會(huì)有兩個(gè)任務(wù)并發(fā)運(yùn)行，因此不會(huì)出現(xiàn)同時(shí)訪問臨界區(qū)的風(fēng)險(xiǎn)；相對(duì)于這些任務(wù)來說，這就從競(jìng)態(tài)條件下保護(hù)了臨界區(qū)。所以如果訪問臨界區(qū)的唯一方式是通過提交到調(diào)度隊(duì)列的任務(wù)，那么你就不需要擔(dān)心臨界區(qū)的安全問題了。
Concurrent Queues 并發(fā)隊(duì)列
在并發(fā)隊(duì)列中的任務(wù)能得到的保證是它們會(huì)按照被添加的順序開始執(zhí)行，但這就是全部的保證了。任務(wù)可能以任意順序完成，你不會(huì)知道何時(shí)開始運(yùn)行下一個(gè)任務(wù)，或者任意時(shí)刻有多少 Block 在運(yùn)行。再說一遍，這完全取決于 GCD 。
下圖展示了一個(gè)示例任務(wù)執(zhí)行計(jì)劃，GCD 管理著四個(gè)并發(fā)任務(wù)：
注意 Block 1,2 和 3 都立馬開始運(yùn)行，一個(gè)接一個(gè)。在 Block 0 開始后，Block 1等待了好一會(huì)兒才開始。同樣， Block 3 在 Block 2 之后才開始，但它先于 Block 2 完成。
何時(shí)開始一個(gè) Block 完全取決于 GCD 。如果一個(gè) Block 的執(zhí)行時(shí)間與另一個(gè)重疊，也是由 GCD 來決定是否將其運(yùn)行在另一個(gè)不同的核心上，如果那個(gè)核心可用，否則就用上下文切換的方式來執(zhí)行不同的 Block 。
有趣的是， GCD 提供給你至少五個(gè)特定的隊(duì)列，可根據(jù)隊(duì)列類型選擇使用。
Queue Types 隊(duì)列類型
首先，系統(tǒng)提供給你一個(gè)叫做 主隊(duì)列（main queue） 的特殊隊(duì)列。和其它串行隊(duì)列一樣，這個(gè)隊(duì)列中的任務(wù)一次只能執(zhí)行一個(gè)。然而，它能保證所有的任務(wù)都在主線程執(zhí)行，而主線程是唯一可用于更新 UI 的線程。這個(gè)隊(duì)列就是用于發(fā)生消息給 UIView 或發(fā)送通知的。
系統(tǒng)同時(shí)提供給你好幾個(gè)并發(fā)隊(duì)列。它們叫做 全局調(diào)度隊(duì)列（Global Dispatch Queues） 。目前的四個(gè)全局隊(duì)列有著不同的優(yōu)先級(jí)：background、low、default 以及 high。要知道，Apple 的 API 也會(huì)使用這些隊(duì)列，所以你添加的任何任務(wù)都不會(huì)是這些隊(duì)列中唯一的任務(wù)。
最后，你也可以創(chuàng)建自己的串行隊(duì)列或并發(fā)隊(duì)列。這就是說，至少有五個(gè)隊(duì)列任你處置：主隊(duì)列、四個(gè)全局調(diào)度隊(duì)列，再加上任何你自己創(chuàng)建的隊(duì)列。
以上是調(diào)度隊(duì)列的大框架！
GCD 的“藝術(shù)”歸結(jié)為選擇合適的隊(duì)列來調(diào)度函數(shù)以提交你的工作。體驗(yàn)這一點(diǎn)的最好方式是走一遍下邊的列子，我們沿途會(huì)提供一些一般性的建議。
入門
既然本教程的目標(biāo)是優(yōu)化且安全的使用 GCD 調(diào)用來自不同線程的代碼，那么你將從一個(gè)近乎完成的叫做 GooglyPuff 的項(xiàng)目入手。
GooglyPuff 是一個(gè)沒有優(yōu)化，線程不安全的應(yīng)用，它使用 Core Image 的人臉檢測(cè) API 來覆蓋一對(duì)曲棍球眼睛到被檢測(cè)到的人臉上。對(duì)于基本的圖像，可以從相機(jī)膠卷選擇，或用預(yù)設(shè)好的URL從互聯(lián)網(wǎng)下載。
完成項(xiàng)目下載之后，將其解壓到某個(gè)方便的目錄，再用 Xcode 打開它并編譯運(yùn)行。這個(gè)應(yīng)用看起來如下圖所示：
注意當(dāng)你選擇 Le Internet 選項(xiàng)下載圖片時(shí)，一個(gè) UIAlertView 過早地彈出。你將在本系列教程地第二部分修復(fù)這個(gè)問題。
這個(gè)項(xiàng)目中有四個(gè)有趣的類：
1. PhotoCollectionViewController：它是應(yīng)用開始的第一個(gè)視圖控制器。它用縮略圖展示所有選定的照片。
2. PhotoDetailViewController：它執(zhí)行添加曲棍球眼睛到圖像上的邏輯，并用一個(gè) UIScrollView 來顯示結(jié)果圖片。
3. Photo：這是一個(gè)類簇，它根據(jù)一個(gè) NSURL 的實(shí)例或一個(gè) ALAsset 的實(shí)例來實(shí)例化照片。這個(gè)類提供一個(gè)圖像、縮略圖以及從 URL 下載的狀態(tài)。
4. PhotoManager：它管理所有 Photo 的實(shí)例.
用 dispatch_async 處理后臺(tái)任務(wù)
回到應(yīng)用并從你的相機(jī)膠卷添加一些照片或使用 Le Internet 選項(xiàng)下載一些。
注意在按下 PhotoCollectionViewController 中的一個(gè) UICollectionViewCell 到生成一個(gè)新的 PhotoDetailViewController 之間花了多久時(shí)間；你會(huì)注意到一個(gè)明顯的滯后，特別是在比較慢的設(shè)備上查看很大的圖。
在重載 UIViewController 的 viewDidLoad 時(shí)容易加入太多雜波（too much clutter），這通常會(huì)引起視圖控制器出現(xiàn)前更長(zhǎng)的等待。如果可能，最好是卸下一些工作放到后臺(tái)，如果它們不是絕對(duì)必須要運(yùn)行在加載時(shí)間里。
這聽起來像是 dispatch_async 能做的事情！
打開 PhotoDetailViewController 并用下面的實(shí)現(xiàn)替換 viewDidLoad ：
-?(void)viewDidLoad
{
[super?viewDidLoad];
NSAssert(_image,?@"Image?not?set;?required?to?use?view?controller");
self.photoImageView.image?=?_image;
//Resize?if?neccessary?to?ensure?it's?not?pixelated
if?(_image.size.height?<=?self.photoImageView.bounds.size.height?&&
_image.size.width?<=?self.photoImageView.bounds.size.width)?{
[self.photoImageView?setContentMode:UIViewContentModeCenter];
}
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH,?0),?^{?//?1
UIImage?*overlayImage?=?[self?faceOverlayImageFromImage:_image];
dispatch_async(dispatch_get_main_queue(),?^{?//?2
[self?fadeInNewImage:overlayImage];?//?3
});
});
}
下面來說明上面的新代碼所做的事：
1. 你首先將工作從主線程移到全局線程。因?yàn)檫@是一個(gè) dispatch_async() ，Block 會(huì)被異步地提交，意味著調(diào)用線程地執(zhí)行將會(huì)繼續(xù)。這就使得 viewDidLoad 更早地在主線程完成，讓加載過程感覺起來更加快速。同時(shí)，一個(gè)人臉檢測(cè)過程會(huì)啟動(dòng)并將在稍后完成。
2. 在這里，人臉檢測(cè)過程完成，并生成了一個(gè)新的圖像。既然你要使用此新圖像更新你的 UIImageView ，那么你就添加一個(gè)新的 Block 到主線程。記住——你必須總是在主線程訪問 UIKit 的類。
3. 最后，你用 fadeInNewImage: 更新 UI ，它執(zhí)行一個(gè)淡入過程切換到新的曲棍球眼睛圖像。
編譯并運(yùn)行你的應(yīng)用；選擇一個(gè)圖像然后你會(huì)注意到視圖控制器加載明顯變快，曲棍球眼睛稍微在之后就加上了。這給應(yīng)用帶來了不錯(cuò)的效果，和之前的顯示差別巨大。
進(jìn)一步，如果你試著加載一個(gè)超大的圖像，應(yīng)用不會(huì)在加載視圖控制器上“掛住”，這就使得應(yīng)用具有很好伸縮性。
正如之前提到的， dispatch_async 添加一個(gè) Block 都隊(duì)列就立即返回了。任務(wù)會(huì)在之后由 GCD 決定執(zhí)行。當(dāng)你需要在后臺(tái)執(zhí)行一個(gè)基于網(wǎng)絡(luò)或 CPU 緊張的任務(wù)時(shí)就使用 dispatch_async ，這樣就不會(huì)阻塞當(dāng)前線程。
下面是一個(gè)關(guān)于在 dispatch_async 上如何以及何時(shí)使用不同的隊(duì)列類型的快速指導(dǎo)：
1. 自定義串行隊(duì)列：當(dāng)你想串行執(zhí)行后臺(tái)任務(wù)并追蹤它時(shí)就是一個(gè)好選擇。這消除了資源爭(zhēng)用，因?yàn)槟阒酪淮沃挥幸粋€(gè)任務(wù)在執(zhí)行。注意若你需要來自某個(gè)方法的數(shù)據(jù)，你必須內(nèi)聯(lián)另一個(gè) Block 來找回它或考慮使用 dispatch_sync。
2. 主隊(duì)列（串行）：這是在一個(gè)并發(fā)隊(duì)列上完成任務(wù)后更新 UI 的共同選擇。要這樣做，你將在一個(gè) Block 內(nèi)部編寫另一個(gè) Block 。以及，如果你在主隊(duì)列調(diào)用 dispatch_async 到主隊(duì)列，你能確保這個(gè)新任務(wù)將在當(dāng)前方法完成后的某個(gè)時(shí)間執(zhí)行。
3. 并發(fā)隊(duì)列：這是在后臺(tái)執(zhí)行非 UI 工作的共同選擇。
使用 dispatch_after 延后工作
稍微考慮一下應(yīng)用的 UX 。是否用戶第一次打開應(yīng)用時(shí)會(huì)困惑于不知道做什么？你是這樣嗎？ :]
如果用戶的 PhotoManager 里還沒有任何照片，那么顯示一個(gè)提示會(huì)是個(gè)好主意！然而，你同樣要考慮用戶的眼睛會(huì)如何在主屏幕上瀏覽：如果你太快的顯示一個(gè)提示，他們的眼睛還徘徊在視圖的其它部分上，他們很可能會(huì)錯(cuò)過它。
顯示提示之前延遲一秒鐘就足夠捕捉到用戶的注意，他們此時(shí)已經(jīng)第一次看過了應(yīng)用。
添加如下代碼到到 PhotoCollectionViewController.m 中 showOrHideNavPrompt 的廢止實(shí)現(xiàn)里：
-?(void)showOrHideNavPrompt
{
NSUInteger?count?=?[[PhotoManager?sharedManager]?photos].count;
double?delayInSeconds?=?1.0;
dispatch_time_t?popTime?=?dispatch_time(DISPATCH_TIME_NOW,?(int64_t)(delayInSeconds?*?NSEC_PER_SEC));?//?1
dispatch_after(popTime,?dispatch_get_main_queue(),?^(void){?//?2
if?(!count)?{
[self.navigationItem?setPrompt:@"Add?photos?with?faces?to?Googlyify?them!"];
}?else?{
[self.navigationItem?setPrompt:nil];
}
});
}
showOrHideNavPrompt 在 viewDidLoad 中執(zhí)行，以及 UICollectionView 被重新加載的任何時(shí)候。按照注釋數(shù)字順序看看：
1. 你聲明了一個(gè)變量指定要延遲的時(shí)長(zhǎng)。
2. 然后等待 delayInSeconds 給定的時(shí)長(zhǎng)，再異步地添加一個(gè) Block 到主線程。
編譯并運(yùn)行應(yīng)用。應(yīng)該有一個(gè)輕微地延遲，這有助于抓住用戶的注意力并展示所要做的事情。
dispatch_after 工作起來就像一個(gè)延遲版的 dispatch_async 。你依然不能控制實(shí)際的執(zhí)行時(shí)間，且一旦 dispatch_after 返回也就不能再取消它。
不知道何時(shí)適合使用 dispatch_after ？
1. 自定義串行隊(duì)列：在一個(gè)自定義串行隊(duì)列上使用 dispatch_after 要小心。你最好堅(jiān)持使用主隊(duì)列。
2. 主隊(duì)列（串行）：是使用 dispatch_after 的好選擇；Xcode 提供了一個(gè)不錯(cuò)的自動(dòng)完成模版。
3. 并發(fā)隊(duì)列：在并發(fā)隊(duì)列上使用 dispatch_after 也要小心；你會(huì)這樣做就比較罕見。還是在主隊(duì)列做這些操作吧。
讓你的單例線程安全
單例，不論喜歡還是討厭，它們?cè)?iOS 上的流行情況就像網(wǎng)上的貓。
一個(gè)常見的擔(dān)憂是它們常常不是線程安全的。這個(gè)擔(dān)憂十分合理，基于它們的用途：?jiǎn)卫３１欢鄠€(gè)控制器同時(shí)訪問。
單例的線程擔(dān)憂范圍從初始化開始，到信息的讀和寫。PhotoManager 類被實(shí)現(xiàn)為單例——它在目前的狀態(tài)下就會(huì)被這些問題所困擾。要看看事情如何很快地失去控制，你將在單例實(shí)例上創(chuàng)建一個(gè)控制好的競(jìng)態(tài)條件。
導(dǎo)航到 PhotoManager.m 并找到 sharedManager ；它看起來如下：
+?(instancetype)sharedManager
{
static?PhotoManager?*sharedPhotoManager?=?nil;
if?(!sharedPhotoManager)?{
sharedPhotoManager?=?[[PhotoManager?alloc]?init];
sharedPhotoManager->_photosArray?=?[NSMutableArray?array];
}
return?sharedPhotoManager;
}
當(dāng)前狀態(tài)下，代碼相當(dāng)簡(jiǎn)單；你創(chuàng)建了一個(gè)單例并初始化一個(gè)叫做 photosArray 的 NSMutableArray 屬性。
然而，if 條件分支不是線程安全的；如果你多次調(diào)用這個(gè)方法，有一個(gè)可能性是在某個(gè)線程（就叫它線程A）上進(jìn)入 if 語句塊并可能在 sharedPhotoManager 被分配內(nèi)存前發(fā)生一個(gè)上下文切換。然后另一個(gè)線程（線程B）可能進(jìn)入 if ，分配單例實(shí)例的內(nèi)存，然后退出。
當(dāng)系統(tǒng)上下文切換回線程A，你會(huì)分配另外一個(gè)單例實(shí)例的內(nèi)存，然后退出。在那個(gè)時(shí)間點(diǎn)，你有了兩個(gè)單例的實(shí)例——很明顯這不是你想要的（譯者注：這還能叫單例嗎？）！
要強(qiáng)制這個(gè)（競(jìng)態(tài)）條件發(fā)生，替換 PhotoManager.m 中的 sharedManager 為下面的實(shí)現(xiàn)：
+?(instancetype)sharedManager
{
static?PhotoManager?*sharedPhotoManager?=?nil;
if?(!sharedPhotoManager)?{
[NSThread?sleepForTimeInterval:2];
sharedPhotoManager?=?[[PhotoManager?alloc]?init];
NSLog(@"Singleton?has?memory?address?at:?%@",?sharedPhotoManager);
[NSThread?sleepForTimeInterval:2];
sharedPhotoManager->_photosArray?=?[NSMutableArray?array];
}
return?sharedPhotoManager;
}
上面的代碼中你用 NSThread 的 sleepForTimeInterval: 類方法來強(qiáng)制發(fā)生一個(gè)上下文切換。
打開 AppDelegate.m 并添加如下代碼到 application:didFinishLaunchingWithOptions: 的最開始處：
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH,?0),?^{
[PhotoManager?sharedManager];
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH,?0),?^{
[PhotoManager?sharedManager];
});
這里創(chuàng)建了多個(gè)異步并發(fā)調(diào)用來實(shí)例化單例，然后引發(fā)上面描述的競(jìng)態(tài)條件。
編譯并運(yùn)行項(xiàng)目；查看控制臺(tái)輸出，你會(huì)看到多個(gè)單例被實(shí)例化，如下所示：
注意到這里有好幾行顯示著不同地址的單例實(shí)例。這明顯違背了單例的目的，對(duì)吧？
這個(gè)輸出向你展示了臨界區(qū)被執(zhí)行多次，而它只應(yīng)該執(zhí)行一次?，F(xiàn)在，固然是你自己強(qiáng)制這樣的狀況發(fā)生，但你可以想像一下這個(gè)狀況會(huì)怎樣在無意間發(fā)生。
注意：基于其它你無法控制的系統(tǒng)事件，NSLog 的數(shù)量有時(shí)會(huì)顯示多個(gè)。線程問題極其難以調(diào)試，因?yàn)樗鼈兺y以重現(xiàn)。
要糾正這個(gè)狀況，實(shí)例化代碼應(yīng)該只執(zhí)行一次，并阻塞其它實(shí)例在 if 條件的臨界區(qū)運(yùn)行。這剛好就是 dispatch_once 能做的事。
在單例初始化方法中用 dispatch_once 取代 if 條件判斷，如下所示：
+?(instancetype)sharedManager
{
static?PhotoManager?*sharedPhotoManager?=?nil;
static?dispatch_once_t?onceToken;
dispatch_once(&onceToken,?^{
[NSThread?sleepForTimeInterval:2];
sharedPhotoManager?=?[[PhotoManager?alloc]?init];
NSLog(@"Singleton?has?memory?address?at:?%@",?sharedPhotoManager);
[NSThread?sleepForTimeInterval:2];
sharedPhotoManager->_photosArray?=?[NSMutableArray?array];
});
return?sharedPhotoManager;
}
編譯并運(yùn)行你的應(yīng)用；查看控制臺(tái)輸出，你會(huì)看到有且僅有一個(gè)單例的實(shí)例——這就是你對(duì)單例的期望！:]
現(xiàn)在你已經(jīng)明白了防止競(jìng)態(tài)條件的重要性，從 AppDelegate.m 中移除 dispatch_async 語句，并用下面的實(shí)現(xiàn)替換 PhotoManager 單例的初始化：
+?(instancetype)sharedManager
{
static?PhotoManager?*sharedPhotoManager?=?nil;
static?dispatch_once_t?onceToken;
dispatch_once(&onceToken,?^{
sharedPhotoManager?=?[[PhotoManager?alloc]?init];
sharedPhotoManager->_photosArray?=?[NSMutableArray?array];
});
return?sharedPhotoManager;
}
dispatch_once() 以線程安全的方式執(zhí)行且僅執(zhí)行其代碼塊一次。試圖訪問臨界區(qū)（即傳遞給 dispatch_once 的代碼）的不同的線程會(huì)在臨界區(qū)已有一個(gè)線程的情況下被阻塞，直到臨界區(qū)完成為止。
需要記住的是，這只是讓訪問共享實(shí)例線程安全。它絕對(duì)沒有讓類本身線程安全。類中可能還有其它競(jìng)態(tài)條件，例如任何操縱內(nèi)部數(shù)據(jù)的情況。這些需要用其它方式來保證線程安全，例如同步訪問數(shù)據(jù)，你將在下面幾個(gè)小節(jié)看到。
處理讀者與寫者問題
線程安全實(shí)例不是處理單例時(shí)的唯一問題。如果單例屬性表示一個(gè)可變對(duì)象，那么你就需要考慮是否那個(gè)對(duì)象自身線程安全。
如果問題中的這個(gè)對(duì)象是一個(gè) Foundation 容器類，那么答案是——“很可能不安全”！Apple 維護(hù)一個(gè)有用且有些心寒的列表，眾多的 Foundation 類都不是線程安全的。 NSMutableArray，已用于你的單例，正在那個(gè)列表里休息。
雖然許多線程可以同時(shí)讀取 NSMutableArray 的一個(gè)實(shí)例而不會(huì)產(chǎn)生問題，但當(dāng)一個(gè)線程正在讀取時(shí)讓另外一個(gè)線程修改數(shù)組就是不安全的。你的單例在目前的狀況下不能預(yù)防這種情況的發(fā)生。
要分析這個(gè)問題，看看 PhotoManager.m 中的 addPhoto:，轉(zhuǎn)載如下：
-?(void)addPhoto:(Photo?*)photo
{
if?(photo)?{
[_photosArray?addObject:photo];
dispatch_async(dispatch_get_main_queue(),?^{
[self?postContentAddedNotification];
});
}
}
這是一個(gè)寫方法，它修改一個(gè)私有可變數(shù)組對(duì)象。
現(xiàn)在看看 photos ，轉(zhuǎn)載如下：
-?(NSArray?*)photos
{
return?[NSArray?arrayWithArray:_photosArray];
}
這是所謂的讀方法，它讀取可變數(shù)組。它為調(diào)用者生成一個(gè)不可變的拷貝，防止調(diào)用者不當(dāng)?shù)馗淖償?shù)組，但這不能提供任何保護(hù)來對(duì)抗當(dāng)一個(gè)線程調(diào)用讀方法 photos 的同時(shí)另一個(gè)線程調(diào)用寫方法 addPhoto: 。
這就是軟件開發(fā)中經(jīng)典的讀者寫者問題。GCD 通過用 dispatch barriers 創(chuàng)建一個(gè)讀者寫者鎖 提供了一個(gè)優(yōu)雅的解決方案。
Dispatch barriers 是一組函數(shù)，在并發(fā)隊(duì)列上工作時(shí)扮演一個(gè)串行式的瓶頸。使用 GCD 的障礙（barrier）API 確保提交的 Block 在那個(gè)特定時(shí)間上是指定隊(duì)列上唯一被執(zhí)行的條目。這就意味著所有的先于調(diào)度障礙提交到隊(duì)列的條目必能在這個(gè) Block 執(zhí)行前完成。
當(dāng)這個(gè) Block 的時(shí)機(jī)到達(dá)，調(diào)度障礙執(zhí)行這個(gè) Block 并確保在那個(gè)時(shí)間里隊(duì)列不會(huì)執(zhí)行任何其它 Block 。一旦完成，隊(duì)列就返回到它默認(rèn)的實(shí)現(xiàn)狀態(tài)。 GCD 提供了同步和異步兩種障礙函數(shù)。
下圖顯示了障礙函數(shù)對(duì)多個(gè)異步隊(duì)列的影響：
注意到正常部分的操作就如同一個(gè)正常的并發(fā)隊(duì)列。但當(dāng)障礙執(zhí)行時(shí)，它本質(zhì)上就如同一個(gè)串行隊(duì)列。也就是，障礙是唯一在執(zhí)行的事物。在障礙完成后，隊(duì)列回到一個(gè)正常并發(fā)隊(duì)列的樣子。
下面是你何時(shí)會(huì)——和不會(huì)——使用障礙函數(shù)的情況：(最佳的使用場(chǎng)景就是“自定義并發(fā)隊(duì)列”，因?yàn)槿植l(fā)隊(duì)列并只有這一個(gè)程序在使用，不能隨便阻斷其他并發(fā)任務(wù)的執(zhí)行)。
1. 自定義串行隊(duì)列：一個(gè)很壞的選擇；障礙不會(huì)有任何幫助，因?yàn)椴还茉鯓?，一個(gè)串行隊(duì)列一次都只執(zhí)行一個(gè)操作。
2. 全局并發(fā)隊(duì)列：要小心；這可能不是最好的主意，因?yàn)槠渌到y(tǒng)可能在使用隊(duì)列而且你不能壟斷它們只為你自己的目的。
3. 自定義并發(fā)隊(duì)列：這對(duì)于原子或臨界區(qū)代碼來說是極佳的選擇。任何你在設(shè)置或?qū)嵗男枰€程安全的事物都是使用障礙的最佳候選。
由于上面唯一像樣的選擇是自定義并發(fā)隊(duì)列，你將創(chuàng)建一個(gè)你自己的隊(duì)列去處理你的障礙函數(shù)并分開讀和寫函數(shù)。且這個(gè)并發(fā)隊(duì)列將允許多個(gè)多操作同時(shí)進(jìn)行。
打開 PhotoManager.m，添加如下私有屬性到類擴(kuò)展中：
@interface?PhotoManager?()
@property?(nonatomic,strong,readonly)?NSMutableArray?*photosArray;
@property?(nonatomic,?strong)?dispatch_queue_t?concurrentPhotoQueue;?///<?Add?this
@end
找到 addPhoto: 并用下面的實(shí)現(xiàn)替換它：
-?(void)addPhoto:(Photo?*)photo
{
if?(photo)?{?//?1
dispatch_barrier_async(self.concurrentPhotoQueue,?^{?//?2
[_photosArray?addObject:photo];?//?3
dispatch_async(dispatch_get_main_queue(),?^{?//?4
[self?postContentAddedNotification];
});
});
}
}
你新寫的函數(shù)是這樣工作的：
1. 在執(zhí)行下面所有的工作前檢查是否有合法的相片。
2. 添加寫操作到你的自定義隊(duì)列。當(dāng)臨界區(qū)在稍后執(zhí)行時(shí)，這將是你隊(duì)列中唯一執(zhí)行的條目。
3. 這是添加對(duì)象到數(shù)組的實(shí)際代碼。由于它是一個(gè)障礙 Block ，這個(gè) Block 永遠(yuǎn)不會(huì)同時(shí)和其它 Block 一起在 concurrentPhotoQueue 中執(zhí)行。
4. 最后你發(fā)送一個(gè)通知說明完成了添加圖片。這個(gè)通知將在主線程被發(fā)送因?yàn)樗鼘?huì)做一些 UI 工作，所以在此為了通知，你異步地調(diào)度另一個(gè)任務(wù)到主線程。
這就處理了寫操作，但你還需要實(shí)現(xiàn) photos 讀方法并實(shí)例化 concurrentPhotoQueue 。
在寫者打擾的情況下，要確保線程安全，你需要在 concurrentPhotoQueue 隊(duì)列上執(zhí)行讀操作。既然你需要從函數(shù)返回，你就不能異步調(diào)度到隊(duì)列，因?yàn)槟菢釉谧x者函數(shù)返回之前不一定運(yùn)行。
在這種情況下，dispatch_sync 就是一個(gè)絕好的候選。
dispatch_sync() 同步地提交工作并在返回前等待它完成。使用 dispatch_sync 跟蹤你的調(diào)度障礙工作，或者當(dāng)你需要等待操作完成后才能使用 Block 處理過的數(shù)據(jù)。如果你使用第二種情況做事，你將不時(shí)看到一個(gè) __block 變量寫在 dispatch_sync 范圍之外，以便返回時(shí)在 dispatch_sync 使用處理過的對(duì)象。
但你需要很小心。想像如果你調(diào)用 dispatch_sync 并放在你已運(yùn)行著的當(dāng)前隊(duì)列。這會(huì)導(dǎo)致死鎖，因?yàn)檎{(diào)用會(huì)一直等待直到 Block 完成，但 Block 不能完成（它甚至不會(huì)開始！），直到當(dāng)前已經(jīng)存在的任務(wù)完成，而當(dāng)前任務(wù)無法完成！這將迫使你自覺于你正從哪個(gè)隊(duì)列調(diào)用——以及你正在傳遞進(jìn)入哪個(gè)隊(duì)列。
下面是一個(gè)快速總覽，關(guān)于在何時(shí)以及何處使用 dispatch_sync ：
1. 自定義串行隊(duì)列：在這個(gè)狀況下要非常小心！如果你正運(yùn)行在一個(gè)隊(duì)列并調(diào)用 dispatch_sync 放在同一個(gè)隊(duì)列，那你就百分百地創(chuàng)建了一個(gè)死鎖。
2. 主隊(duì)列（串行）：同上面的理由一樣，必須非常小心！這個(gè)狀況同樣有潛在的導(dǎo)致死鎖的情況。
3. 并發(fā)隊(duì)列：這才是做同步工作的好選擇，不論是通過調(diào)度障礙，或者需要等待一個(gè)任務(wù)完成才能執(zhí)行進(jìn)一步處理的情況。
繼續(xù)在 PhotoManager.m 上工作，用下面的實(shí)現(xiàn)替換 photos ：
-?(NSArray?*)photos
{
__block?NSArray?*array;?//?1
dispatch_sync(self.concurrentPhotoQueue,?^{?//?2
array?=?[NSArray?arrayWithArray:_photosArray];?//?3
});
return?array;
}
這就是你的讀函數(shù)。按順序看看編過號(hào)的注釋，有這些：
1. __block 關(guān)鍵字允許對(duì)象在 Block 內(nèi)可變。沒有它，array 在 Block 內(nèi)部就只是只讀的，你的代碼甚至不能通過編譯。
2. 在 concurrentPhotoQueue 上同步調(diào)度來執(zhí)行讀操作。
3. 將相片數(shù)組存儲(chǔ)在 array 內(nèi)并返回它。
最后，你需要實(shí)例化你的 concurrentPhotoQueue 屬性。修改 sharedManager 以便像下面這樣初始化隊(duì)列：
+?(instancetype)sharedManager
{
static?PhotoManager?*sharedPhotoManager?=?nil;
static?dispatch_once_t?onceToken;
dispatch_once(&onceToken,?^{
sharedPhotoManager?=?[[PhotoManager?alloc]?init];
sharedPhotoManager->_photosArray?=?[NSMutableArray?array];
//?ADD?THIS:
sharedPhotoManager->_concurrentPhotoQueue?=?dispatch_queue_create("com.selander.GooglyPuff.photoQueue",
DISPATCH_QUEUE_CONCURRENT);
});
return?sharedPhotoManager;
}
這里使用 dispatch_queue_create 初始化 concurrentPhotoQueue 為一個(gè)并發(fā)隊(duì)列。第一個(gè)參數(shù)是反向DNS樣式命名慣例；確保它是描述性的，將有助于調(diào)試。第二個(gè)參數(shù)指定你的隊(duì)列是串行還是并發(fā)。
注意：當(dāng)你在網(wǎng)上搜索例子時(shí)，你會(huì)經(jīng)?？慈藗儌鬟f 0 或者 NULL 給 dispatch_queue_create 的第二個(gè)參數(shù)。這是一個(gè)創(chuàng)建串行隊(duì)列的過時(shí)方式；明確你的參數(shù)總是更好。
恭喜——你的 PhotoManager 單例現(xiàn)在是線程安全的了。不論你在何處或怎樣讀或?qū)懩愕恼掌?，你都有這樣的自信，即它將以安全的方式完成，不會(huì)出現(xiàn)任何驚嚇。
A Visual Review of Queueing 隊(duì)列的虛擬回顧
依然沒有 100% 地掌握 GCD 的要領(lǐng)？確保你可以使用 GCD 函數(shù)輕松地創(chuàng)建簡(jiǎn)單的例子，使用斷點(diǎn)和 NSLog 語句保證自己明白當(dāng)下發(fā)生的情況。
我在下面提供了兩個(gè) GIF動(dòng)畫來幫助你鞏固對(duì) dispatch_async 和 dispatch_sync 的理解。包含在每個(gè) GIF 中的代碼可以提供視覺輔助；仔細(xì)注意 GIF 左邊顯示代碼斷點(diǎn)的每一步，以及右邊相關(guān)隊(duì)列的狀態(tài)。
dispatch_sync 回顧
-?(void)viewDidLoad
{
[super?viewDidLoad];
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH,?0),?^{
NSLog(@"First?Log");
});
NSLog(@"Second?Log");
}
下面是圖中幾個(gè)步驟的說明：
1. 主隊(duì)列一路按順序執(zhí)行任務(wù)——接著是一個(gè)實(shí)例化 UIViewController 的任務(wù)，其中包含了 viewDidLoad 。
2. viewDidLoad 在主線程執(zhí)行。
3. 主線程目前在 viewDidLoad 內(nèi)，正要到達(dá) dispatch_sync 。
4. dispatch_sync Block 被添加到一個(gè)全局隊(duì)列中，將在稍后執(zhí)行。進(jìn)程將在主線程掛起直到該 Block 完成。同時(shí)，全局隊(duì)列并發(fā)處理任務(wù)；要記得 Block 在全局隊(duì)列中將按照 FIFO 順序出列，但可以并發(fā)執(zhí)行。
5. 全局隊(duì)列處理 dispatch_sync Block 加入之前已經(jīng)出現(xiàn)在隊(duì)列中的任務(wù)。
6. 終于，輪到 dispatch_sync Block 。
7. 這個(gè) Block 完成，因此主線程上的任務(wù)可以恢復(fù)。
8. viewDidLoad 方法完成，主隊(duì)列繼續(xù)處理其他任務(wù)。
dispatch_sync 添加任務(wù)到一個(gè)隊(duì)列并等待直到任務(wù)完成。dispatch_async 做類似的事情，但不同之處是它不會(huì)等待任務(wù)的完成，而是立即繼續(xù)“調(diào)用線程”的其它任務(wù)。
dispatch_async 回顧
-?(void)viewDidLoad
{
[super?viewDidLoad];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH,?0),?^{
NSLog(@"First?Log");
});
NSLog(@"Second?Log");
}
1.主隊(duì)列一路按順序執(zhí)行任務(wù)——接著是一個(gè)實(shí)例化 UIViewController 的任務(wù)，其中包含了 viewDidLoad 。
2. viewDidLoad 在主線程執(zhí)行。
3.主線程目前在 viewDidLoad 內(nèi)，正要到達(dá) dispatch_async 。
4.dispatch_async Block 被添加到一個(gè)全局隊(duì)列中，將在稍后執(zhí)行。
5.viewDidLoad 在添加 dispatch_async 到全局隊(duì)列后繼續(xù)進(jìn)行，主線程把注意力轉(zhuǎn)向剩下的任務(wù)。同時(shí)，全局隊(duì)列并發(fā)地處理它未完成地任務(wù)。記住 Block 在全局隊(duì)列中將按照 FIFO 順序出列，但可以并發(fā)執(zhí)行。
6.添加到 dispatch_async 的代碼塊開始執(zhí)行。
7.dispatch_async Block 完成，兩個(gè) NSLog 語句將它們的輸出放在控制臺(tái)上。
在這個(gè)特定的實(shí)例中，第二個(gè) NSLog 語句執(zhí)行，跟著是第一個(gè) NSLog 語句。并不總是這樣——著取決于給定時(shí)刻硬件正在做的事情，而且你無法控制或知曉哪個(gè)語句會(huì)先執(zhí)行?！暗谝粋€(gè)” NSLog 在某些調(diào)用情況下會(huì)第一個(gè)執(zhí)行。
下一步怎么走？
在本教程中，你學(xué)習(xí)了如何讓你的代碼線程安全，以及在執(zhí)行 CPU 密集型任務(wù)時(shí)如何保持主線程的響應(yīng)性。
你可以下載GooglyPuff 項(xiàng)目，它包含了目前所有本教程中編寫的實(shí)現(xiàn)。在本教程的第二部分，你將繼續(xù)改進(jìn)這個(gè)項(xiàng)目。
如果你計(jì)劃優(yōu)化你自己的應(yīng)用，那你應(yīng)該用 Instruments 中的 Time Profile 模版分析你的工作。對(duì)這個(gè)工具的使用超出了本教程的范圍，你可以看看如何使用Instruments來得到一個(gè)很好的概述。
同時(shí)請(qǐng)確保在真實(shí)設(shè)備上分析，而在模擬器上測(cè)試會(huì)對(duì)程序速度產(chǎn)生非常不準(zhǔn)確的印象。
在教程的下一部分，你將更加深入到 GCD 的 API 中，做一些更 Cool 的東西。
CocoaChina是全球最大的蘋果開發(fā)中文社區(qū)，官方微信每日定時(shí)推送各種精彩的 研發(fā)教程資源和工具，介紹app推廣營(yíng)銷經(jīng)驗(yàn)，最新企業(yè)招聘和外包信息，以及Cocos2d引擎、Cocos Studio開發(fā)工具包的最新動(dòng)態(tài)及培訓(xùn)信息。關(guān)注微信可以第一時(shí)間了解最新產(chǎn)品和服務(wù)動(dòng)態(tài)，微信在手，天下我有！
