本文翻譯自 www.raywenderlich.com/60749/grand…
原作者：Derek Selander
譯者：@nixzhu
==========================================
雖然 GCD 已經出現過一段時間了，但不是每個人都明瞭其主要內容。這是可以理解的；併發一直很棘手，而 GCD 是基於 C 的 API ，它們就像一組尖銳的稜角戳進 Objective-C 的平滑世界。我們將分兩個部分的教程來深入學習 GCD 。
在這兩部分的系列中，第一個部分的將解釋 GCD 是做什麼的，並從許多基本的 GCD 函式中找出幾個來展示。在第二部分，你將學到幾個 GCD 提供的高階函式。
什麼是 GCD
GCD 是 libdispatch 的市場名稱，而 libdispatch 作為 Apple 的一個庫，為併發程式碼在多核硬體（跑 iOS 或 OS X ）上執行提供有力支援。它具有以下優點：
- GCD 能通過推遲昂貴計算任務並在後臺執行它們來改善你的應用的響應效能。
- GCD 提供一個易於使用的併發模型而不僅僅只是鎖和執行緒，以幫助我們避開併發陷阱。
- GCD 具有在常見模式（例如單例）上用更高效能的原語優化你的程式碼的潛在能力。
本教程假設你對 Block 和 GCD 有基礎瞭解。如果你對 GCD 完全陌生，先看看 iOS 上的多執行緒和 GCD 入門教程 學習其要領。
GCD 術語
要理解 GCD ，你要先熟悉與執行緒和併發相關的幾個概念。這兩者都可能模糊和微妙，所以在開始 GCD 之前先簡要地回顧一下它們。
Serial vs. Concurrent 序列 vs. 併發
這些術語描述當任務相對於其它任務被執行，任務序列執行就是每次只有一個任務被執行，任務併發執行就是在同一時間可以有多個任務被執行。
雖然這些術語被廣泛使用，本教程中你可以將任務設定為一個 Objective-C 的 Block 。不明白什麼是 Block ？看看 iOS 5 教程中的如何使用 Block 。實際上，你也可以在 GCD 上使用函式指標，但在大多數場景中，這實際上更難於使用。Block 就是更加容易些！
Synchronous vs. Asynchronous 同步 vs. 非同步
在 GCD 中，這些術語描述當一個函式相對於另一個任務完成，此任務是該函式要求 GCD 執行的。一個_同步_函式只在完成了它預定的任務後才返回。
一個_非同步_函式，剛好相反，會立即返回，預定的任務會完成但不會等它完成。因此，一個非同步函式不會阻塞當前執行緒去執行下一個函式。
注意——當你讀到同步函式“阻塞（Block）”當前執行緒，或函式是一個“阻塞”函式或阻塞操作時，不要被搞糊塗了！動詞“阻塞”描述了函式如何影響它所在的執行緒而與名詞“程式碼塊（Block）”沒有關係。程式碼塊描述了用 Objective-C 編寫的一個匿名函式，它能定義一個任務並被提交到 GCD 。
譯者注：中文不會有這個問題，“阻塞”和“程式碼塊”是兩個詞。
Critical Section 臨界區
就是一段程式碼不能被併發執行，也就是，兩個執行緒不能同時執行這段程式碼。這很常見，因為程式碼去操作一個共享資源，例如一個變數若能被併發程式訪問，那麼它很可能會變質（譯者注：它的值不再可信）。
Race Condition 競態條件
這種狀況是指基於特定序列或時機的事件的軟體系統以不受控制的方式執行的行為，例如程式的併發任務執行的確切順序。競態條件可導致無法預測的行為，而不能通過程式碼檢查立即發現。
Deadlock 死鎖
兩個（有時更多）東西——在大多數情況下，是執行緒——所謂的死鎖是指它們都卡住了，並等待對方完成或執行其它操作。第一個不能完成是因為它在等待第二個的完成。但第二個也不能完成，因為它在等待第一個的完成。
Thread Safe 執行緒安全
執行緒安全的程式碼能在多執行緒或併發任務中被安全的呼叫，而不會導致任何問題（資料損壞，崩潰，等）。執行緒不安全的程式碼在某個時刻只能在一個上下文中執行。一個執行緒安全程式碼的例子是 NSDictionary 。你可以在同一時間在多個執行緒中使用它而不會有問題。另一方面，NSMutableDictionary 就不是執行緒安全的，應該保證一次只能有一個執行緒訪問它。
Context Switch 上下文切換
一個上下文切換指當你在單個程式裡切換執行不同的執行緒時儲存與恢復執行狀態的過程。這個過程在編寫多工應用時很普遍，但會帶來一些額外的開銷。
Concurrency vs Parallelism 併發與並行
併發和並行通常被一起提到，所以值得花些時間解釋它們之間的區別。
併發程式碼的不同部分可以“同步”執行。然而，該怎樣發生或是否發生都取決於系統。多核裝置通過並行來同時執行多個執行緒；然而，為了使單核裝置也能實現這一點，它們必須先執行一個執行緒，執行一個上下文切換，然後執行另一個執行緒或程式。這通常發生地足夠快以致給我們併發執行地錯覺，如下圖所示：
雖然你可以編寫程式碼在 GCD 下併發執行，但 GCD 會決定有多少並行的需求。並行_要求_併發，但併發並不能_保證_並行。
更深入的觀點是併發實際上是關於_構造_。當你在腦海中用 GCD 編寫程式碼，你組織你的程式碼來暴露能同時執行的多個工作片段，以及不能同時執行的那些。如果你想深入此主題，看看 這個由Rob Pike做的精彩的講座 。
Queues 佇列
GCD 提供有 dispatch queues 來處理程式碼塊，這些佇列管理你提供給 GCD 的任務並用 FIFO 順序執行這些任務。這就保證了第一個被新增到佇列裡的任務會是佇列中第一個開始的任務，而第二個被新增的任務將第二個開始，如此直到佇列的終點。
所有的排程佇列（dispatch queues）自身都是執行緒安全的，你能從多個執行緒並行的訪問它們。當你瞭解了排程佇列如何為你自己程式碼的不同部分提供執行緒安全後，GCD的優點就是顯而易見的。關於這一點的關鍵是選擇正確_型別_的排程佇列和正確的_排程函式_來提交你的工作。
在本節你會看到兩種排程佇列，都是由 GCD 提供的，然後看一些描述如何用排程函式新增工作到佇列的例子。
Serial Queues 序列佇列
序列佇列中的任務一次執行一個，每個任務只在前一個任務完成時才開始。而且，你不知道在一個 Block 結束和下一個開始之間的時間長度，如下圖所示：
這些任務的執行時機受到 GCD 的控制；唯一能確保的事情是 GCD 一次只執行一個任務，並且按照我們新增到佇列的順序來執行。
由於在序列佇列中不會有兩個任務併發執行，因此不會出現同時訪問臨界區的風險；相對於這些任務來說，這就從競態條件下保護了臨界區。所以如果訪問臨界區的唯一方式是通過提交到排程佇列的任務，那麼你就不需要擔心臨界區的安全問題了。
Concurrent Queues 併發佇列
在併發佇列中的任務能得到的保證是它們會按照被新增的順序開始執行，但這就是全部的保證了。任務可能以任意順序完成，你不會知道何時開始執行下一個任務，或者任意時刻有多少 Block 在執行。再說一遍，這完全取決於 GCD 。
下圖展示了一個示例任務執行計劃，GCD 管理著四個併發任務：
注意 Block 1,2 和 3 都立馬開始執行，一個接一個。在 Block 0 開始後，Block 1等待了好一會兒才開始。同樣， Block 3 在 Block 2 之後才開始，但它先於 Block 2 完成。
何時開始一個 Block 完全取決於 GCD 。如果一個 Block 的執行時間與另一個重疊，也是由 GCD 來決定是否將其執行在另一個不同的核心上，如果那個核心可用，否則就用上下文切換的方式來執行不同的 Block 。
有趣的是， GCD 提供給你至少五個特定的佇列，可根據佇列型別選擇使用。
Queue Types 佇列型別
首先，系統提供給你一個叫做 主佇列（main queue） 的特殊佇列。和其它序列佇列一樣，這個佇列中的任務一次只能執行一個。然而，它能保證所有的任務都在主執行緒執行，而主執行緒是唯一可用於更新 UI 的執行緒。這個佇列就是用於發生訊息給 UIView 或傳送通知的。
系統同時提供給你好幾個併發佇列。它們叫做 全域性排程佇列（Global Dispatch Queues） 。目前的四個全域性佇列有著不同的優先順序：background、low、default 以及 high。要知道，Apple 的 API 也會使用這些佇列，所以你新增的任何任務都不會是這些佇列中唯一的任務。
最後，你也可以建立自己的序列佇列或併發佇列。這就是說，至少有_五個_佇列任你處置：主佇列、四個全域性排程佇列，再加上任何你自己建立的佇列。
以上是排程佇列的大框架！
GCD 的“藝術”歸結為選擇合適的佇列來排程函式以提交你的工作。體驗這一點的最好方式是走一遍下邊的列子，我們沿途會提供一些一般性的建議。
入門
既然本教程的目標是優化且安全的使用 GCD 呼叫來自不同執行緒的程式碼，那麼你將從一個近乎完成的叫做 GooglyPuff 的專案入手。
GooglyPuff 是一個沒有優化，執行緒不安全的應用，它使用 Core Image 的人臉檢測 API 來覆蓋一對曲棍球眼睛到被檢測到的人臉上。對於基本的影象，可以從相機膠捲選擇，或用預設好的URL從網際網路下載。
完成專案下載之後，將其解壓到某個方便的目錄，再用 Xcode 開啟它並編譯執行。這個應用看起來如下圖所示：
注意當你選擇 Le Internet 選項下載圖片時，一個 UIAlertView 過早地彈出。你將在本系列教程地第二部分修復這個問題。
這個專案中有四個有趣的類：
- PhotoCollectionViewController：它是應用開始的第一個檢視控制器。它用縮圖展示所有選定的照片。
- PhotoDetailViewController：它執行新增曲棍球眼睛到影象上的邏輯，並用一個 UIScrollView 來顯示結果圖片。
- Photo：這是一個類簇，它根據一個
NSURL的例項或一個ALAsset的例項來例項化照片。這個類提供一個影象、縮圖以及從 URL 下載的狀態。 - PhotoManager：它管理所有
Photo的例項.
用 dispatch_async 處理後臺任務
回到應用並從你的相機膠捲新增一些照片或使用 Le Internet 選項下載一些。
注意在按下 PhotoCollectionViewController 中的一個 UICollectionViewCell 到生成一個新的 PhotoDetailViewController 之間花了多久時間；你會注意到一個明顯的滯後，特別是在比較慢的裝置上檢視很大的圖。
在過載 UIViewController 的 viewDidLoad 時容易加入太多雜亂的工作（too much clutter），這通常會引起檢視控制器出現前更長的等待。如果可能，最好是卸下一些工作放到後臺，如果它們不是絕對必須要執行在載入時間裡。
這聽起來像是 dispatch_async 能做的事情！
開啟 PhotoDetailViewController 並用下面的實現替換 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
});
});
}
複製程式碼下面來說明上面的新程式碼所做的事：
- 你首先將工作從主執行緒移到全域性執行緒。因為這是一個
dispatch_async()，Block 會被非同步地提交，意味著呼叫執行緒地執行將會繼續。這就使得viewDidLoad更早地在主執行緒完成，讓載入過程感覺起來更加快速。同時，一個人臉檢測過程會啟動並將在稍後完成。 - 在這裡，人臉檢測過程完成，並生成了一個新的影象。既然你要使用此新影象更新你的
UIImageView，那麼你就新增一個新的 Block 到主執行緒。記住——你必須總是在主執行緒訪問 UIKit 的類。 - 最後，你用
fadeInNewImage:更新 UI ，它執行一個淡入過程切換到新的曲棍球眼睛影象。
編譯並執行你的應用；選擇一個影象然後你會注意到檢視控制器載入明顯變快，曲棍球眼睛稍微在之後就加上了。這給應用帶來了不錯的效果，和之前的顯示差別巨大。
進一步，如果你試著載入一個超大的影象，應用不會在載入檢視控制器上“掛住”，這就使得應用具有很好伸縮性。
正如之前提到的， dispatch_async 新增一個 Block 到佇列就立即返回了。任務會在之後由 GCD 決定執行。當你需要在後臺執行一個基於網路或 CPU 緊張的任務時就使用 dispatch_async ，這樣就不會阻塞當前執行緒。
下面是一個關於在 dispatch_async 上如何以及何時使用不同的佇列型別的快速指導：
- 自定義序列佇列：當你想序列執行後臺任務並追蹤它時就是一個好選擇。這消除了資源爭用，因為你知道一次只有一個任務在執行。注意若你需要來自某個方法的資料，你必須內聯另一個 Block 來找回它或考慮使用
dispatch_sync。 - 主佇列（序列）：這是在一個併發佇列上完成任務後更新 UI 的共同選擇。要這樣做，你將在一個 Block 內部編寫另一個 Block 。以及，如果你在主佇列呼叫
dispatch_async到主佇列，你能確保這個新任務將在當前方法完成後的某個時間執行。 - 併發佇列：這是在後臺執行非 UI 工作的共同選擇。
使用 dispatch_after 延後工作
稍微考慮一下應用的 UX 。是否使用者第一次開啟應用時會困惑於不知道做什麼？你是這樣嗎？ :]
如果使用者的 PhotoManager 裡還沒有任何照片，那麼顯示一個提示會是個好主意！然而，你同樣要考慮使用者的眼睛會如何在主螢幕上瀏覽：如果你太快的顯示一個提示，他們的眼睛還徘徊在檢視的其它部分上，他們很可能會錯過它。
顯示提示之前延遲一秒鐘就足夠捕捉到使用者的注意，他們此時已經第一次看過了應用。
新增如下程式碼到到 PhotoCollectionViewController.m 中 showOrHideNavPrompt 的廢止實現裡：
- (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 中執行，以及 UICollectionView 被重新載入的任何時候。按照註釋數字順序看看：
- 你宣告瞭一個變數指定要延遲的時長。
- 然後等待
delayInSeconds給定的時長，再非同步地新增一個 Block 到主執行緒。
編譯並執行應用。應該有一個輕微地延遲，這有助於抓住使用者的注意力並展示所要做的事情。
dispatch_after 工作起來就像一個延遲版的 dispatch_async 。你依然不能控制實際的執行時間，且一旦 dispatch_after 返回也就不能再取消它。
不知道何時適合使用 dispatch_after ？
- 自定義序列佇列：在一個自定義序列佇列上使用
dispatch_after要小心。你最好堅持使用主佇列。 - 主佇列（序列）：是使用
dispatch_after的好選擇；Xcode 提供了一個不錯的自動完成模版。 - 併發佇列：在併發佇列上使用
dispatch_after也要小心；你會這樣做就比較罕見。還是在主佇列做這些操作吧。
讓你的單例執行緒安全
單例，不論喜歡還是討厭，它們在 iOS 上的流行情況就像網上的貓。 :]
一個常見的擔憂是它們常常不是執行緒安全的。這個擔憂十分合理，基於它們的用途：單例常常被多個控制器同時訪問。
單例的執行緒擔憂範圍從初始化開始，到資訊的讀和寫。PhotoManager 類被實現為單例——它在目前的狀態下就會被這些問題所困擾。要看看事情如何很快地失去控制，你將在單例例項上建立一個控制好的競態條件。
導航到 PhotoManager.m 並找到 sharedManager ；它看起來如下：
+ (instancetype)sharedManager
{
static PhotoManager *sharedPhotoManager = nil;
if (!sharedPhotoManager) {
sharedPhotoManager = [[PhotoManager alloc] init];
sharedPhotoManager->_photosArray = [NSMutableArray array];
}
return sharedPhotoManager;
}
複製程式碼當前狀態下，程式碼相當簡單；你建立了一個單例並初始化一個叫做 photosArray 的 NSMutableArray 屬性。
然而，if 條件分支不是執行緒安全的；如果你多次呼叫這個方法，有一個可能性是在某個執行緒（就叫它執行緒A）上進入 if 語句塊並可能在 sharedPhotoManager 被分配記憶體前發生一個上下文切換。然後另一個執行緒（執行緒B）可能進入 if ，分配單例例項的記憶體，然後退出。
當系統上下文切換回執行緒A，你會分配另外一個單例例項的記憶體，然後退出。在那個時間點，你有了兩個單例的例項——很明顯這不是你想要的（譯者注：這還能叫單例嗎？）！
要強制這個（競態）條件發生，替換 PhotoManager.m 中的 sharedManager 為下面的實現：
+ (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: 類方法來強制發生一個上下文切換。
開啟 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];
});
複製程式碼這裡建立了多個非同步併發呼叫來例項化單例，然後引發上面描述的競態條件。
編譯並執行專案；檢視控制檯輸出，你會看到多個單例被例項化，如下所示：
注意到這裡有好幾行顯示著不同地址的單例例項。這明顯違背了單例的目的，對吧？:]
這個輸出向你展示了臨界區被執行多次，而它只應該執行一次。現在，固然是你自己強制這樣的狀況發生，但你可以想像一下這個狀況會怎樣在無意間發生。
注意：基於其它你無法控制的系統事件，NSLog 的數量有時會顯示多個。執行緒問題極其難以除錯，因為它們往往難以重現。
要糾正這個狀況，例項化程式碼應該只執行一次，並阻塞其它例項在 if 條件的臨界區執行。這剛好就是 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;
}
複製程式碼編譯並執行你的應用；檢視控制檯輸出，你會看到有且僅有一個單例的例項——這就是你對單例的期望！:]
現在你已經明白了防止競態條件的重要性，從 AppDelegate.m 中移除 dispatch_async 語句，並用下面的實現替換 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() 以執行緒安全的方式執行且僅執行其程式碼塊一次。試圖訪問臨界區（即傳遞給 dispatch_once 的程式碼）的不同的執行緒會在臨界區已有一個執行緒的情況下被阻塞，直到臨界區完成為止。
需要記住的是，這只是讓訪問共享例項執行緒安全。它絕對沒有讓類本身執行緒安全。類中可能還有其它競態條件，例如任何操縱內部資料的情況。這些需要用其它方式來保證執行緒安全，例如同步訪問資料，你將在下面幾個小節看到。
處理讀者與寫者問題
執行緒安全例項不是處理單例時的唯一問題。如果單例屬性表示一個可變物件，那麼你就需要考慮是否那個物件自身執行緒安全。
如果問題中的這個物件是一個 Foundation 容器類，那麼答案是——“很可能不安全”！Apple 維護一個有用且有些心寒的列表，眾多的 Foundation 類都不是執行緒安全的。 NSMutableArray，已用於你的單例，正在那個列表裡休息。
雖然許多執行緒可以同時讀取 NSMutableArray 的一個例項而不會產生問題，但當一個執行緒正在讀取時讓另外一個執行緒修改陣列就是不安全的。你的單例在目前的狀況下不能預防這種情況的發生。
要分析這個問題，看看 PhotoManager.m 中的 addPhoto:，轉載如下：
- (void)addPhoto:(Photo *)photo
{
if (photo) {
[_photosArray addObject:photo];
dispatch_async(dispatch_get_main_queue(), ^{
[self postContentAddedNotification];
});
}
}
複製程式碼這是一個寫方法，它修改一個私有可變陣列物件。
現在看看 photos ，轉載如下：
- (NSArray *)photos
{
return [NSArray arrayWithArray:_photosArray];
}
複製程式碼這是所謂的讀方法，它讀取可變陣列。它為呼叫者生成一個不可變的拷貝，防止呼叫者不當地改變陣列，但這不能提供任何保護來對抗當一個執行緒呼叫讀方法 photos 的同時另一個執行緒呼叫寫方法 addPhoto: 。
這就是軟體開發中經典的讀者寫者問題。GCD 通過用 dispatch barriers 建立一個讀者寫者鎖 提供了一個優雅的解決方案。
Dispatch barriers 是一組函式，在併發佇列上工作時扮演一個序列式的瓶頸。使用 GCD 的障礙（barrier）API 確保提交的 Block 在那個特定時間上是指定佇列上唯一被執行的條目。這就意味著所有的先於排程障礙提交到佇列的條目必能在這個 Block 執行前完成。
當這個 Block 的時機到達，排程障礙執行這個 Block 並確保在那個時間裡佇列不會執行任何其它 Block 。一旦完成，佇列就返回到它預設的實現狀態。 GCD 提供了同步和非同步兩種障礙函式。
下圖顯示了障礙函式對多個非同步佇列的影響：
注意到正常部分的操作就如同一個正常的併發佇列。但當障礙執行時，它本質上就如同一個序列佇列。也就是，障礙是唯一在執行的事物。在障礙完成後，佇列回到一個正常併發佇列的樣子。
下面是你何時會——和不會——使用障礙函式的情況：
- 自定義序列佇列：一個很壞的選擇；障礙不會有任何幫助，因為不管怎樣，一個序列佇列一次都只執行一個操作。
- 全域性併發佇列：要小心；這可能不是最好的主意，因為其它系統可能在使用佇列而且你不能壟斷它們只為你自己的目的。
- 自定義併發佇列：這對於原子或臨界區程式碼來說是極佳的選擇。任何你在設定或例項化的需要執行緒安全的事物都是使用障礙的最佳候選。
由於上面唯一像樣的選擇是自定義併發佇列，你將建立一個你自己的佇列去處理你的障礙函式並分開讀和寫函式。且這個併發佇列將允許多個多操作同時進行。
開啟 PhotoManager.m，新增如下私有屬性到類擴充套件中：
@interface PhotoManager ()
@property (nonatomic,strong,readonly) NSMutableArray *photosArray;
@property (nonatomic, strong) dispatch_queue_t concurrentPhotoQueue; ///< Add this
@end
複製程式碼找到 addPhoto: 並用下面的實現替換它：
- (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];
});
});
}
}
複製程式碼你新寫的函式是這樣工作的：
- 在執行下面所有的工作前檢查是否有合法的相片。
- 新增寫操作到你的自定義佇列。當臨界區在稍後執行時，這將是你佇列中唯一執行的條目。
- 這是新增物件到陣列的實際程式碼。由於它是一個障礙 Block ，這個 Block 永遠不會同時和其它 Block 一起在 concurrentPhotoQueue 中執行。
- 最後你傳送一個通知說明完成了新增圖片。這個通知將在主執行緒被髮送因為它將會做一些 UI 工作，所以在此為了通知，你非同步地排程另一個任務到主執行緒。
這就處理了寫操作，但你還需要實現 photos 讀方法並例項化 concurrentPhotoQueue 。
在寫者打擾的情況下，要確保執行緒安全，你需要在 concurrentPhotoQueue 佇列上執行讀操作。既然你需要從函式返回，你就不能非同步排程到佇列，因為那樣在讀者函式返回之前不一定執行。
在這種情況下，dispatch_sync 就是一個絕好的候選。
dispatch_sync() 同步地提交工作並在返回前等待它完成。使用 dispatch_sync 跟蹤你的排程障礙工作，或者當你需要等待操作完成後才能使用 Block 處理過的資料。如果你使用第二種情況做事，你將不時看到一個 __block 變數寫在 dispatch_sync 範圍之外，以便返回時在 dispatch_sync 使用處理過的物件。
但你需要很小心。想像如果你呼叫 dispatch_sync 並放在你已執行著的當前佇列。這會導致死鎖，因為呼叫會一直等待直到 Block 完成，但 Block 不能完成（它甚至不會開始！），直到當前已經存在的任務完成，而當前任務無法完成！這將迫使你自覺於你正從哪個佇列呼叫——以及你正在傳遞進入哪個佇列。
下面是一個快速總覽，關於在何時以及何處使用 dispatch_sync ：
- 自定義序列佇列：在這個狀況下要非常小心！如果你正執行在一個佇列並呼叫
dispatch_sync放在同一個佇列，那你就百分百地建立了一個死鎖。 - 主佇列（序列）：同上面的理由一樣，必須非常小心！這個狀況同樣有潛在的導致死鎖的情況。
- 併發佇列：這才是做同步工作的好選擇，不論是通過排程障礙，或者需要等待一個任務完成才能執行進一步處理的情況。
繼續在 PhotoManager.m 上工作，用下面的實現替換 photos ：
- (NSArray *)photos
{
__block NSArray *array; // 1
dispatch_sync(self.concurrentPhotoQueue, ^{ // 2
array = [NSArray arrayWithArray:_photosArray]; // 3
});
return array;
}
複製程式碼這就是你的讀函式。按順序看看編過號的註釋，有這些：
__block關鍵字允許物件在 Block 內可變。沒有它，array在 Block 內部就只是只讀的，你的程式碼甚至不能通過編譯。- 在
concurrentPhotoQueue上同步排程來執行讀操作。 - 將相片陣列儲存在
array內並返回它。
最後，你需要例項化你的 concurrentPhotoQueue 屬性。修改 sharedManager 以便像下面這樣初始化佇列：
+ (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 為一個併發佇列。第一個引數是反向DNS樣式命名慣例；確保它是描述性的，將有助於除錯。第二個引數指定你的佇列是序列還是併發。
注意：當你在網上搜尋例子時，你會經常看人們傳遞
0或者NULL給dispatch_queue_create的第二個引數。這是一個建立序列佇列的過時方式；明確你的引數總是更好。
恭喜——你的 PhotoManager 單例現在是執行緒安全的了。不論你在何處或怎樣讀或寫你的照片，你都有這樣的自信，即它將以安全的方式完成，不會出現任何驚嚇。
A Visual Review of Queueing 佇列的虛擬回顧
依然沒有 100% 地掌握 GCD 的要領？確保你可以使用 GCD 函式輕鬆地建立簡單的例子，使用斷點和 NSLog 語句保證自己明白當下發生的情況。
我在下面提供了兩個 GIF動畫來幫助你鞏固對 dispatch_async 和 dispatch_sync 的理解。包含在每個 GIF 中的程式碼可以提供視覺輔助；仔細注意 GIF 左邊顯示程式碼斷點的每一步，以及右邊相關佇列的狀態。
dispatch_sync 回顧
- (void)viewDidLoad
{
[super viewDidLoad];
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
NSLog(@"First Log");
});
NSLog(@"Second Log");
}
複製程式碼下面是圖中幾個步驟的說明：
- 主佇列一路按順序執行任務——接著是一個例項化
UIViewController的任務，其中包含了viewDidLoad。 viewDidLoad在主執行緒執行。- 主執行緒目前在
viewDidLoad內，正要到達dispatch_sync。 dispatch_syncBlock 被新增到一個全域性佇列中，將在稍後執行。程式將在主執行緒掛起直到該 Block 完成。同時，全域性佇列併發處理任務；要記得 Block 在全域性佇列中將按照 FIFO 順序出列，但可以併發執行。- 全域性佇列處理
dispatch_syncBlock 加入之前已經出現在佇列中的任務。 - 終於，輪到
dispatch_syncBlock 。 - 這個 Block 完成，因此主執行緒上的任務可以恢復。
viewDidLoad方法完成，主佇列繼續處理其他任務。
dispatch_sync 新增任務到一個佇列並等待直到任務完成。dispatch_async 做類似的事情，但不同之處是它不會等待任務的完成，而是立即繼續“呼叫執行緒”的其它任務。
dispatch_async 回顧
- (void)viewDidLoad
{
[super viewDidLoad];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
NSLog(@"First Log");
});
NSLog(@"Second Log");
}
複製程式碼- 主佇列一路按順序執行任務——接著是一個例項化
UIViewController的任務，其中包含了viewDidLoad。 viewDidLoad在主執行緒執行。- 主執行緒目前在
viewDidLoad內，正要到達dispatch_async。 dispatch_asyncBlock 被新增到一個全域性佇列中，將在稍後執行。viewDidLoad在新增dispatch_async到全域性佇列後繼續進行，主執行緒把注意力轉向剩下的任務。同時，全域性佇列併發地處理它未完成地任務。記住 Block 在全域性佇列中將按照 FIFO 順序出列，但可以併發執行。- 新增到
dispatch_async的程式碼塊開始執行。 dispatch_asyncBlock 完成，兩個NSLog語句將它們的輸出放在控制檯上。
在這個特定的例項中，第二個 NSLog 語句執行，跟著是第一個 NSLog 語句。並不總是這樣——著取決於給定時刻硬體正在做的事情，而且你無法控制或知曉哪個語句會先執行。“第一個” NSLog 在某些呼叫情況下會第一個執行。
下一步怎麼走？
在本教程中，你學習瞭如何讓你的程式碼執行緒安全，以及在執行 CPU 密集型任務時如何保持主執行緒的響應性。
你可以下載 GooglyPuff 專案，它包含了目前所有本教程中編寫的實現。在本教程的第二部分，你將繼續改進這個專案。
如果你計劃優化你自己的應用，那你應該用 Instruments 中的 Time Profile 模版分析你的工作。對這個工具的使用超出了本教程的範圍，你可以看看 如何使用Instruments 來得到一個很好的概述。
同時請確保在真實裝置上分析，而在模擬器上測試會對程式速度產生非常不準確的印象。
在教程的下一部分，你將更加深入到 GCD 的 API 中，做一些更 Cool 的東西。
如果你有任何問題或評論，可自由地加入下方的討論！