GCD 深入理解：第一部分
本文翻譯自?http://www.raywenderlich.com/60749/grand-central-dispatch-in-depth-part-1
原作者：Derek Selander
譯者：@nixzhu
雖然 GCD 已經(jīng)出現(xiàn)過一段時間了，但不是每個人都明了其主要內(nèi)容。這是可以理解的；并發(fā)一直很棘手，而 GCD 是基于 C 的 API ，它們就像一組尖銳的棱角戳進 Objective-C 的平滑世界。我們將分兩個部分的教程來深入學(xué)習(xí) GCD 。
在這兩部分的系列中，第一個部分的將解釋 GCD 是做什么的，并從許多基本的 GCD 函數(shù)中找出幾個來展示。在第二部分，你將學(xué)到幾個 GCD 提供的高級函數(shù)。
什么是 GCD
GCD 是?libdispatch?的市場名稱，而 libdispatch 作為 Apple 的一個庫，為并發(fā)代碼在多核硬件（跑 iOS 或 OS X ）上執(zhí)行提供有力支持。它具有以下優(yōu)點：
- GCD 能通過推遲昂貴計算任務(wù)并在后臺運行它們來改善你的應(yīng)用的響應(yīng)性能。
- GCD 提供一個易于使用的并發(fā)模型而不僅僅只是鎖和線程，以幫助我們避開并發(fā)陷阱。
- GCD 具有在常見模式（例如單例）上用更高性能的原語優(yōu)化你的代碼的潛在能力。
本教程假設(shè)你對 Block 和 GCD 有基礎(chǔ)了解。如果你對 GCD 完全陌生，先看看?iOS 上的多線程和 GCD 入門教程?學(xué)習(xí)其要領(lǐng)。
GCD 術(shù)語
要理解 GCD ，你要先熟悉與線程和并發(fā)相關(guān)的幾個概念。這兩者都可能模糊和微妙，所以在開始 GCD 之前先簡要地回顧一下它們。
Serial vs. Concurrent 串行 vs. 并發(fā)
這些術(shù)語描述當(dāng)任務(wù)相對于其它任務(wù)被執(zhí)行，任務(wù)串行執(zhí)行就是每次只有一個任務(wù)被執(zhí)行，任務(wù)并發(fā)執(zhí)行就是在同一時間可以有多個任務(wù)被執(zhí)行。
雖然這些術(shù)語被廣泛使用，本教程中你可以將任務(wù)設(shè)定為一個 Objective-C 的 Block 。不明白什么是 Block ？看看?iOS 5 教程中的如何使用 Block?。實際上，你也可以在 GCD 上使用函數(shù)指針，但在大多數(shù)場景中，這實際上更難于使用。Block 就是更加容易些！
Synchronous vs. Asynchronous 同步 vs. 異步
在 GCD 中，這些術(shù)語描述當(dāng)一個函數(shù)相對于另一個任務(wù)完成，此任務(wù)是該函數(shù)要求 GCD 執(zhí)行的。一個同步函數(shù)只在完成了它預(yù)定的任務(wù)后才返回。
一個異步函數(shù)，剛好相反，會立即返回，預(yù)定的任務(wù)會完成但不會等它完成。因此，一個異步函數(shù)不會阻塞當(dāng)前線程去執(zhí)行下一個函數(shù)。
注意——當(dāng)你讀到同步函數(shù)“阻塞（Block）”當(dāng)前線程，或函數(shù)是一個“阻塞”函數(shù)或阻塞操作時，不要被搞糊涂了！動詞“阻塞”描述了函數(shù)如何影響它所在的線程而與名詞“代碼塊（Block）”沒有關(guān)系。代碼塊描述了用 Objective-C 編寫的一個匿名函數(shù)，它能定義一個任務(wù)并被提交到 GCD 。
譯者注：中文不會有這個問題，“阻塞”和“代碼塊”是兩個詞。
Critical Section 臨界區(qū)
就是一段代碼不能被并發(fā)執(zhí)行，也就是，兩個線程不能同時執(zhí)行這段代碼。這很常見，因為代碼去操作一個共享資源，例如一個變量若能被并發(fā)進程訪問，那么它很可能會變質(zhì)（譯者注：它的值不再可信）。
Race Condition 競態(tài)條件
這種狀況是指基于特定序列或時機的事件的軟件系統(tǒng)以不受控制的方式運行的行為，例如程序的并發(fā)任務(wù)執(zhí)行的確切順序。競態(tài)條件可導(dǎo)致無法預(yù)測的行為，而不能通過代碼檢查立即發(fā)現(xiàn)。
Deadlock 死鎖
兩個（有時更多）東西——在大多數(shù)情況下，是線程——所謂的死鎖是指它們都卡住了，并等待對方完成或執(zhí)行其它操作。第一個不能完成是因為它在等待第二個的完成。但第二個也不能完成，因為它在等待第一個的完成。
Thread Safe 線程安全
線程安全的代碼能在多線程或并發(fā)任務(wù)中被安全的調(diào)用，而不會導(dǎo)致任何問題（數(shù)據(jù)損壞，崩潰，等）。線程不安全的代碼在某個時刻只能在一個上下文中運行。一個線程安全代碼的例子是?NSDictionary?。你可以在同一時間在多個線程中使用它而不會有問題。另一方面，NSMutableDictionary?就不是線程安全的，應(yīng)該保證一次只能有一個線程訪問它。
Context Switch 上下文切換
一個上下文切換指當(dāng)你在單個進程里切換執(zhí)行不同的線程時存儲與恢復(fù)執(zhí)行狀態(tài)的過程。這個過程在編寫多任務(wù)應(yīng)用時很普遍，但會帶來一些額外的開銷。
Concurrency vs Parallelism 并發(fā)與并行
并發(fā)和并行通常被一起提到，所以值得花些時間解釋它們之間的區(qū)別。
并發(fā)代碼的不同部分可以“同步”執(zhí)行。然而，該怎樣發(fā)生或是否發(fā)生都取決于系統(tǒng)。多核設(shè)備通過并行來同時執(zhí)行多個線程；然而，為了使單核設(shè)備也能實現(xiàn)這一點，它們必須先運行一個線程，執(zhí)行一個上下文切換，然后運行另一個線程或進程。這通常發(fā)生地足夠快以致給我們并發(fā)執(zhí)行地錯覺，如下圖所示：
雖然你可以編寫代碼在 GCD 下并發(fā)執(zhí)行，但 GCD 會決定有多少并行的需求。并行要求并發(fā)，但并發(fā)并不能保證并行。
更深入的觀點是并發(fā)實際上是關(guān)于構(gòu)造。當(dāng)你在腦海中用 GCD 編寫代碼，你組織你的代碼來暴露能同時運行的多個工作片段，以及不能同時運行的那些。如果你想深入此主題，看看?這個由Rob Pike做的精彩的講座?。
Queues 隊列
GCD 提供有?dispatch queues?來處理代碼塊，這些隊列管理你提供給 GCD 的任務(wù)并用 FIFO 順序執(zhí)行這些任務(wù)。這就保證了第一個被添加到隊列里的任務(wù)會是隊列中第一個開始的任務(wù)，而第二個被添加的任務(wù)將第二個開始，如此直到隊列的終點。
所有的調(diào)度隊列（dispatch queues）自身都是線程安全的，你能從多個線程并行的訪問它們。當(dāng)你了解了調(diào)度隊列如何為你自己代碼的不同部分提供線程安全后，GCD的優(yōu)點就是顯而易見的。關(guān)于這一點的關(guān)鍵是選擇正確類型的調(diào)度隊列和正確的調(diào)度函數(shù)來提交你的工作。
在本節(jié)你會看到兩種調(diào)度隊列，都是由 GCD 提供的，然后看一些描述如何用調(diào)度函數(shù)添加工作到隊列的例子。
Serial Queues 串行隊列
串行隊列中的任務(wù)一次執(zhí)行一個，每個任務(wù)只在前一個任務(wù)完成時才開始。而且，你不知道在一個 Block 結(jié)束和下一個開始之間的時間長度，如下圖所示：
這些任務(wù)的執(zhí)行時機受到 GCD 的控制；唯一能確保的事情是 GCD 一次只執(zhí)行一個任務(wù)，并且按照我們添加到隊列的順序來執(zhí)行。
由于在串行隊列中不會有兩個任務(wù)并發(fā)運行，因此不會出現(xiàn)同時訪問臨界區(qū)的風(fēng)險；相對于這些任務(wù)來說，這就從競態(tài)條件下保護了臨界區(qū)。所以如果訪問臨界區(qū)的唯一方式是通過提交到調(diào)度隊列的任務(wù)，那么你就不需要擔(dān)心臨界區(qū)的安全問題了。
Concurrent Queues 并發(fā)隊列
在并發(fā)隊列中的任務(wù)能得到的保證是它們會按照被添加的順序開始執(zhí)行，但這就是全部的保證了。任務(wù)可能以任意順序完成，你不會知道何時開始運行下一個任務(wù)，或者任意時刻有多少 Block 在運行。再說一遍，這完全取決于 GCD 。
下圖展示了一個示例任務(wù)執(zhí)行計劃，GCD 管理著四個并發(fā)任務(wù)：
注意 Block 1,2 和 3 都立馬開始運行，一個接一個。在 Block 0 開始后，Block 1等待了好一會兒才開始。同樣， Block 3 在 Block 2 之后才開始，但它先于 Block 2 完成。
何時開始一個 Block 完全取決于 GCD 。如果一個 Block 的執(zhí)行時間與另一個重疊，也是由 GCD 來決定是否將其運行在另一個不同的核心上，如果那個核心可用，否則就用上下文切換的方式來執(zhí)行不同的 Block 。
有趣的是， GCD 提供給你至少五個特定的隊列，可根據(jù)隊列類型選擇使用。
Queue Types 隊列類型
首先，系統(tǒng)提供給你一個叫做?主隊列（main queue）?的特殊隊列。和其它串行隊列一樣，這個隊列中的任務(wù)一次只能執(zhí)行一個。然而，它能保證所有的任務(wù)都在主線程執(zhí)行，而主線程是唯一可用于更新 UI 的線程。這個隊列就是用于發(fā)生消息給?UIView?或發(fā)送通知的。
系統(tǒng)同時提供給你好幾個并發(fā)隊列。它們叫做?全局調(diào)度隊列（Global Dispatch Queues）?。目前的四個全局隊列有著不同的優(yōu)先級：background、low、default?以及?high。要知道，Apple 的 API 也會使用這些隊列，所以你添加的任何任務(wù)都不會是這些隊列中唯一的任務(wù)。
最后，你也可以創(chuàng)建自己的串行隊列或并發(fā)隊列。這就是說，至少有五個隊列任你處置：主隊列、四個全局調(diào)度隊列，再加上任何你自己創(chuàng)建的隊列。
以上是調(diào)度隊列的大框架！
GCD 的“藝術(shù)”歸結(jié)為選擇合適的隊列來調(diào)度函數(shù)以提交你的工作。體驗這一點的最好方式是走一遍下邊的列子，我們沿途會提供一些一般性的建議。
入門
既然本教程的目標(biāo)是優(yōu)化且安全的使用 GCD 調(diào)用來自不同線程的代碼，那么你將從一個近乎完成的叫做?GooglyPuff?的項目入手。
GooglyPuff 是一個沒有優(yōu)化，線程不安全的應(yīng)用，它使用 Core Image 的人臉檢測 API 來覆蓋一對曲棍球眼睛到被檢測到的人臉上。對于基本的圖像，可以從相機膠卷選擇，或用預(yù)設(shè)好的URL從互聯(lián)網(wǎng)下載。
點擊此處下載項目
完成項目下載之后，將其解壓到某個方便的目錄，再用 Xcode 打開它并編譯運行。這個應(yīng)用看起來如下圖所示：
注意當(dāng)你選擇?Le Internet?選項下載圖片時，一個?UIAlertView?過早地彈出。你將在本系列教程地第二部分修復(fù)這個問題。
這個項目中有四個有趣的類：
- PhotoCollectionViewController：它是應(yīng)用開始的第一個視圖控制器。它用縮略圖展示所有選定的照片。
- PhotoDetailViewController：它執(zhí)行添加曲棍球眼睛到圖像上的邏輯，并用一個 UIScrollView 來顯示結(jié)果圖片。
- Photo：這是一個類簇，它根據(jù)一個?NSURL?的實例或一個?ALAsset?的實例來實例化照片。這個類提供一個圖像、縮略圖以及從 URL 下載的狀態(tài)。
- PhotoManager：它管理所有?Photo?的實例.
用 dispatch_async 處理后臺任務(wù)
回到應(yīng)用并從你的相機膠卷添加一些照片或使用?Le Internet?選項下載一些。
注意在按下?PhotoCollectionViewController?中的一個?UICollectionViewCell?到生成一個新的?PhotoDetailViewController?之間花了多久時間；你會注意到一個明顯的滯后，特別是在比較慢的設(shè)備上查看很大的圖。
在重載?UIViewController 的 viewDidLoad?時容易加入太多雜亂的工作（too much clutter），這通常會引起視圖控制器出現(xiàn)前更長的等待。如果可能，最好是卸下一些工作放到后臺，如果它們不是絕對必須要運行在加載時間里。
這聽起來像是?dispatch_async?能做的事情！
打開?PhotoDetailViewController?并用下面的實現(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 pixelatedif (_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), ^{ // 1UIImage *overlayImage = [self faceOverlayImageFromImage:_image];dispatch_async(dispatch_get_main_queue(), ^{ // 2[self fadeInNewImage:overlayImage]; // 3});}); }下面來說明上面的新代碼所做的事：
編譯并運行你的應(yīng)用；選擇一個圖像然后你會注意到視圖控制器加載明顯變快，曲棍球眼睛稍微在之后就加上了。這給應(yīng)用帶來了不錯的效果，和之前的顯示差別巨大。
進一步，如果你試著加載一個超大的圖像，應(yīng)用不會在加載視圖控制器上“掛住”，這就使得應(yīng)用具有很好伸縮性。
正如之前提到的，?dispatch_async?添加一個 Block 到隊列就立即返回了。任務(wù)會在之后由 GCD 決定執(zhí)行。當(dāng)你需要在后臺執(zhí)行一個基于網(wǎng)絡(luò)或 CPU 緊張的任務(wù)時就使用?dispatch_async?，這樣就不會阻塞當(dāng)前線程。
下面是一個關(guān)于在?dispatch_async?上如何以及何時使用不同的隊列類型的快速指導(dǎo)：
- 自定義串行隊列：當(dāng)你想串行執(zhí)行后臺任務(wù)并追蹤它時就是一個好選擇。這消除了資源爭用，因為你知道一次只有一個任務(wù)在執(zhí)行。注意若你需要來自某個方法的數(shù)據(jù)，你必須內(nèi)聯(lián)另一個 Block 來找回它或考慮使用?dispatch_sync。
- 主隊列（串行）：這是在一個并發(fā)隊列上完成任務(wù)后更新 UI 的共同選擇。要這樣做，你將在一個 Block 內(nèi)部編寫另一個 Block 。以及，如果你在主隊列調(diào)用?dispatch_async?到主隊列，你能確保這個新任務(wù)將在當(dāng)前方法完成后的某個時間執(zhí)行。
- 并發(fā)隊列：這是在后臺執(zhí)行非 UI 工作的共同選擇。
使用 dispatch_after 延后工作
稍微考慮一下應(yīng)用的 UX 。是否用戶第一次打開應(yīng)用時會困惑于不知道做什么？你是這樣嗎？ :]
如果用戶的?PhotoManager?里還沒有任何照片，那么顯示一個提示會是個好主意！然而，你同樣要考慮用戶的眼睛會如何在主屏幕上瀏覽：如果你太快的顯示一個提示，他們的眼睛還徘徊在視圖的其它部分上，他們很可能會錯過它。
顯示提示之前延遲一秒鐘就足夠捕捉到用戶的注意，他們此時已經(jīng)第一次看過了應(yīng)用。
添加如下代碼到到 PhotoCollectionViewController.m 中 showOrHideNavPrompt 的廢止實現(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ù)字順序看看：
編譯并運行應(yīng)用。應(yīng)該有一個輕微地延遲，這有助于抓住用戶的注意力并展示所要做的事情。
dispatch_after?工作起來就像一個延遲版的?dispatch_async?。你依然不能控制實際的執(zhí)行時間，且一旦?dispatch_after?返回也就不能再取消它。
不知道何時適合使用?dispatch_after?？
- 自定義串行隊列：在一個自定義串行隊列上使用?dispatch_after?要小心。你最好堅持使用主隊列。
- 主隊列（串行）：是使用?dispatch_after?的好選擇；Xcode 提供了一個不錯的自動完成模版。
- 并發(fā)隊列：在并發(fā)隊列上使用?dispatch_after?也要小心；你會這樣做就比較罕見。還是在主隊列做這些操作吧。
讓你的單例線程安全
單例，不論喜歡還是討厭，它們在 iOS 上的流行情況就像網(wǎng)上的貓。 :]
一個常見的擔(dān)憂是它們常常不是線程安全的。這個擔(dān)憂十分合理，基于它們的用途：單例常常被多個控制器同時訪問。
單例的線程擔(dān)憂范圍從初始化開始，到信息的讀和寫。PhotoManager?類被實現(xiàn)為單例——它在目前的狀態(tài)下就會被這些問題所困擾。要看看事情如何很快地失去控制，你將在單例實例上創(chuà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)簡單；你創(chuàng)建了一個單例并初始化一個叫做?photosArray?的?NSMutableArray?屬性。
然而，if?條件分支不是線程安全的；如果你多次調(diào)用這個方法，有一個可能性是在某個線程（就叫它線程A）上進入?if語句塊并可能在?sharedPhotoManager?被分配內(nèi)存前發(fā)生一個上下文切換。然后另一個線程（線程B）可能進入?if?，分配單例實例的內(nèi)存，然后退出。
當(dāng)系統(tǒng)上下文切換回線程A，你會分配另外一個單例實例的內(nèi)存，然后退出。在那個時間點，你有了兩個單例的實例——很明顯這不是你想要的（譯者注：這還能叫單例嗎？）！
要強制這個（競態(tài)）條件發(fā)生，替換?PhotoManager.m?中的?sharedManager?為下面的實現(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:?類方法來強制發(fā)生一個上下文切換。
打開?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)建了多個異步并發(fā)調(diào)用來實例化單例，然后引發(fā)上面描述的競態(tài)條件。
編譯并運行項目；查看控制臺輸出，你會看到多個單例被實例化，如下所示：
注意到這里有好幾行顯示著不同地址的單例實例。這明顯違背了單例的目的，對吧？:]
這個輸出向你展示了臨界區(qū)被執(zhí)行多次，而它只應(yīng)該執(zhí)行一次。現(xiàn)在，固然是你自己強制這樣的狀況發(fā)生，但你可以想像一下這個狀況會怎樣在無意間發(fā)生。
注意：基于其它你無法控制的系統(tǒng)事件，NSLog 的數(shù)量有時會顯示多個。線程問題極其難以調(diào)試，因為它們往往難以重現(xiàn)。
要糾正這個狀況，實例化代碼應(yīng)該只執(zhí)行一次，并阻塞其它實例在?if?條件的臨界區(qū)運行。這剛好就是?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īng)用；查看控制臺輸出，你會看到有且僅有一個單例的實例——這就是你對單例的期望！:]
現(xiàn)在你已經(jīng)明白了防止競態(tài)條件的重要性，從?AppDelegate.m?中移除?dispatch_async?語句，并用下面的實現(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?的代碼）的不同的線程會在臨界區(qū)已有一個線程的情況下被阻塞，直到臨界區(qū)完成為止。
需要記住的是，這只是讓訪問共享實例線程安全。它絕對沒有讓類本身線程安全。類中可能還有其它競態(tài)條件，例如任何操縱內(nèi)部數(shù)據(jù)的情況。這些需要用其它方式來保證線程安全，例如同步訪問數(shù)據(jù)，你將在下面幾個小節(jié)看到。
處理讀者與寫者問題
線程安全實例不是處理單例時的唯一問題。如果單例屬性表示一個可變對象，那么你就需要考慮是否那個對象自身線程安全。
如果問題中的這個對象是一個 Foundation 容器類，那么答案是——“很可能不安全”！Apple 維護一個有用且有些心寒的列表，眾多的 Foundation 類都不是線程安全的。?NSMutableArray，已用于你的單例，正在那個列表里休息。
雖然許多線程可以同時讀取?NSMutableArray?的一個實例而不會產(chǎn)生問題，但當(dāng)一個線程正在讀取時讓另外一個線程修改數(shù)組就是不安全的。你的單例在目前的狀況下不能預(yù)防這種情況的發(fā)生。
要分析這個問題，看看?PhotoManager.m?中的?addPhoto:，轉(zhuǎn)載如下：
- (void)addPhoto:(Photo *)photo {if (photo) {[_photosArray addObject:photo];dispatch_async(dispatch_get_main_queue(), ^{[self postContentAddedNotification];});} }這是一個寫方法，它修改一個私有可變數(shù)組對象。
現(xiàn)在看看?photos?，轉(zhuǎn)載如下：
- (NSArray *)photos {return [NSArray arrayWithArray:_photosArray]; }這是所謂的讀方法，它讀取可變數(shù)組。它為調(diào)用者生成一個不可變的拷貝，防止調(diào)用者不當(dāng)?shù)馗淖償?shù)組，但這不能提供任何保護來對抗當(dāng)一個線程調(diào)用讀方法?photos?的同時另一個線程調(diào)用寫方法?addPhoto:?。
這就是軟件開發(fā)中經(jīng)典的讀者寫者問題。GCD 通過用?dispatch barriers?創(chuàng)建一個讀者寫者鎖?提供了一個優(yōu)雅的解決方案。
Dispatch barriers 是一組函數(shù)，在并發(fā)隊列上工作時扮演一個串行式的瓶頸。使用 GCD 的障礙（barrier）API 確保提交的 Block 在那個特定時間上是指定隊列上唯一被執(zhí)行的條目。這就意味著所有的先于調(diào)度障礙提交到隊列的條目必能在這個 Block 執(zhí)行前完成。
當(dāng)這個 Block 的時機到達(dá)，調(diào)度障礙執(zhí)行這個 Block 并確保在那個時間里隊列不會執(zhí)行任何其它 Block 。一旦完成，隊列就返回到它默認(rèn)的實現(xiàn)狀態(tài)。 GCD 提供了同步和異步兩種障礙函數(shù)。
下圖顯示了障礙函數(shù)對多個異步隊列的影響：
注意到正常部分的操作就如同一個正常的并發(fā)隊列。但當(dāng)障礙執(zhí)行時，它本質(zhì)上就如同一個串行隊列。也就是，障礙是唯一在執(zhí)行的事物。在障礙完成后，隊列回到一個正常并發(fā)隊列的樣子。
下面是你何時會——和不會——使用障礙函數(shù)的情況：
- 自定義串行隊列：一個很壞的選擇；障礙不會有任何幫助，因為不管怎樣，一個串行隊列一次都只執(zhí)行一個操作。
- 全局并發(fā)隊列：要小心；這可能不是最好的主意，因為其它系統(tǒng)可能在使用隊列而且你不能壟斷它們只為你自己的目的。
- 自定義并發(fā)隊列：這對于原子或臨界區(qū)代碼來說是極佳的選擇。任何你在設(shè)置或?qū)嵗男枰€程安全的事物都是使用障礙的最佳候選。
由于上面唯一像樣的選擇是自定義并發(fā)隊列，你將創(chuàng)建一個你自己的隊列去處理你的障礙函數(shù)并分開讀和寫函數(shù)。且這個并發(fā)隊列將允許多個多操作同時進行。
打開?PhotoManager.m，添加如下私有屬性到類擴展中：
@interface PhotoManager () @property (nonatomic,strong,readonly) NSMutableArray *photosArray; @property (nonatomic, strong) dispatch_queue_t concurrentPhotoQueue; ///< Add this @end找到?addPhoto:?并用下面的實現(xiàn)替換它：
- (void)addPhoto:(Photo *)photo {if (photo) { // 1dispatch_barrier_async(self.concurrentPhotoQueue, ^{ // 2 [_photosArray addObject:photo]; // 3dispatch_async(dispatch_get_main_queue(), ^{ // 4[self postContentAddedNotification]; });});} }你新寫的函數(shù)是這樣工作的：
這就處理了寫操作，但你還需要實現(xiàn)?photos?讀方法并實例化?concurrentPhotoQueue?。
在寫者打擾的情況下，要確保線程安全，你需要在?concurrentPhotoQueue?隊列上執(zhí)行讀操作。既然你需要從函數(shù)返回，你就不能異步調(diào)度到隊列，因為那樣在讀者函數(shù)返回之前不一定運行。
在這種情況下，dispatch_sync?就是一個絕好的候選。
dispatch_sync()?同步地提交工作并在返回前等待它完成。使用?dispatch_sync?跟蹤你的調(diào)度障礙工作，或者當(dāng)你需要等待操作完成后才能使用 Block 處理過的數(shù)據(jù)。如果你使用第二種情況做事，你將不時看到一個?__block?變量寫在?dispatch_sync?范圍之外，以便返回時在?dispatch_sync?使用處理過的對象。
但你需要很小心。想像如果你調(diào)用?dispatch_sync?并放在你已運行著的當(dāng)前隊列。這會導(dǎo)致死鎖，因為調(diào)用會一直等待直到 Block 完成，但 Block 不能完成（它甚至不會開始！），直到當(dāng)前已經(jīng)存在的任務(wù)完成，而當(dāng)前任務(wù)無法完成！這將迫使你自覺于你正從哪個隊列調(diào)用——以及你正在傳遞進入哪個隊列。
下面是一個快速總覽，關(guān)于在何時以及何處使用?dispatch_sync?：
- 自定義串行隊列：在這個狀況下要非常小心！如果你正運行在一個隊列并調(diào)用?dispatch_sync?放在同一個隊列，那你就百分百地創(chuàng)建了一個死鎖。
- 主隊列（串行）：同上面的理由一樣，必須非常小心！這個狀況同樣有潛在的導(dǎo)致死鎖的情況。
- 并發(fā)隊列：這才是做同步工作的好選擇，不論是通過調(diào)度障礙，或者需要等待一個任務(wù)完成才能執(zhí)行進一步處理的情況。
繼續(xù)在?PhotoManager.m?上工作，用下面的實現(xiàn)替換?photos?：
- (NSArray *)photos {__block NSArray *array; // 1dispatch_sync(self.concurrentPhotoQueue, ^{ // 2array = [NSArray arrayWithArray:_photosArray]; // 3});return array; }這就是你的讀函數(shù)。按順序看看編過號的注釋，有這些：
最后，你需要實例化你的?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?為一個并發(fā)隊列。第一個參數(shù)是反向DNS樣式命名慣例；確保它是描述性的，將有助于調(diào)試。第二個參數(shù)指定你的隊列是串行還是并發(fā)。
注意：當(dāng)你在網(wǎng)上搜索例子時，你會經(jīng)常看人們傳遞?0?或者?NULL?給?dispatch_queue_create?的第二個參數(shù)。這是一個創(chuàng)建串行隊列的過時方式；明確你的參數(shù)總是更好。
恭喜——你的?PhotoManager?單例現(xiàn)在是線程安全的了。不論你在何處或怎樣讀或?qū)懩愕恼掌?#xff0c;你都有這樣的自信，即它將以安全的方式完成，不會出現(xiàn)任何驚嚇。
A Visual Review of Queueing 隊列的虛擬回顧
依然沒有 100% 地掌握 GCD 的要領(lǐng)？確保你可以使用 GCD 函數(shù)輕松地創(chuàng)建簡單的例子，使用斷點和?NSLog?語句保證自己明白當(dāng)下發(fā)生的情況。
我在下面提供了兩個 GIF動畫來幫助你鞏固對?dispatch_async?和?dispatch_sync?的理解。包含在每個 GIF 中的代碼可以提供視覺輔助；仔細(xì)注意 GIF 左邊顯示代碼斷點的每一步，以及右邊相關(guān)隊列的狀態(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"); }
下面是圖中幾個步驟的說明：
dispatch_sync?添加任務(wù)到一個隊列并等待直到任務(wù)完成。dispatch_async?做類似的事情，但不同之處是它不會等待任務(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"); }
在這個特定的實例中，第二個?NSLog?語句執(zhí)行，跟著是第一個?NSLog?語句。并不總是這樣——著取決于給定時刻硬件正在做的事情，而且你無法控制或知曉哪個語句會先執(zhí)行。“第一個”?NSLog?在某些調(diào)用情況下會第一個執(zhí)行。
下一步怎么走？
在本教程中，你學(xué)習(xí)了如何讓你的代碼線程安全，以及在執(zhí)行 CPU 密集型任務(wù)時如何保持主線程的響應(yīng)性。
你可以下載?GooglyPuff 項目，它包含了目前所有本教程中編寫的實現(xiàn)。在本教程的第二部分，你將繼續(xù)改進這個項目。
如果你計劃優(yōu)化你自己的應(yīng)用，那你應(yīng)該用?Instruments?中的?Time Profile?模版分析你的工作。對這個工具的使用超出了本教程的范圍，你可以看看?如何使用Instruments?來得到一個很好的概述。
同時請確保在真實設(shè)備上分析，而在模擬器上測試會對程序速度產(chǎn)生非常不準(zhǔn)確的印象。
在教程的下一部分，你將更加深入到 GCD 的 API 中，做一些更 Cool 的東西。
如果你有任何問題或評論，可自由地加入下方的討論！
譯者注：歡迎轉(zhuǎn)載，但請一定注明出處！?https://github.com/nixzhu/dev-blog
歡迎轉(zhuǎn)發(fā)此條微博?http://weibo.com/2076580237/B0tjrEQr9?以分享給更多人！
如果你認(rèn)為這篇翻譯不錯，也有閑錢，那你可以用支付寶隨便捐助一點，以慰勞譯者的辛苦：
總結(jié)
以上是生活随笔為你收集整理的GCD 深入理解：第一部分的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 自定义Xcode代码模板：Code Sn
- 下一篇： IOS安装CocoaPods完整流程