很久很久以前：
或许GCD中使用最多并且被滥用功能的就是 dispatch_once 了。正确的用法看起来是这样的：
+ (UIColor *)boringColor {
static UIColor * color;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
color = [UIColor colorWithRed:0.380f green:0.376f blue:0.376f alpha:1.000f];
});
return color;
}
上面的 block 只会运行一次。并且在连续的调用中，这种检查是很高效的。你能使用它来初始化全局数据比如单例。
要注意的是，使用 dispatch_once_t 会使得测试变得非常困难（单例和测试不是很好配合）。
要确保 onceToken 被声明为 static ，或者有全局作用域。任何其他的情况都会导致无法预知的行为。换句话说，不要把 dispatch_once_t 作为一个对象的成员变量，或者类似的情形。
退回到远古时代（其实也就是几年前），人们会使用 pthread_once ，因为 dispatch_once_t 更容易使用并且不易出错，所以你永远都不会再用到 pthread_once 了。
延时执行：
另一个常见的小伙伴就是 dispatch_after 了。它使工作延后执行。它是很强大的，但是要注意：你很容易就陷入到一堆麻烦中。一般用法是这样的：
- (void)testFunction {
double delayInSeconds = 2.0;
dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t) (delayInSeconds * NSEC_PER_SEC));
dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
[self bar];
});
}
第一眼看上去这段代码是极好的，但是这里存在一些缺点。我们不能（直接）取消我们已经提交到 dispatch_after 的代码，它将会运行。
另外一个需要注意的事情就是，当人们使用 dispatch_after 去处理他们代码中存在的时序 bug 时，会存在一些有问题的倾向。一些代码执行的过早而你很可能不知道为什么会这样，所以你把这段代码放到了 dispatch_after 中，现在一切运行正常了。但是几周以后，之前的工作不起作用了。由于你并不十分清楚你自己代码的执行次序，调试代码就变成了一场噩梦。所以不要像上面这样做。
大多数的情况下，你最好把代码放到正确的位置。如果代码放到 -viewWillAppear 太早，那么或许 -viewDidAppear 就是正确的地方。
通过在自己代码中建立直接调用（类似 -viewDidAppear ）而不是依赖于 dispatch_after ，你会为自己省去很多麻烦。
如果你需要一些事情在某个特定的时刻运行，那么 dispatch_after 或许会是个好的选择。但是我还是推荐使用NSTimer，这个API虽然有点笨重，但是它允许你取消定时器的触发。
队列：
GCD 中一个基本的代码块就是队列。当使用队列的时候，给它们一个明显的标签会帮自己不少忙。在调试时，这个标签会在 Xcode (和 lldb)中显示，这会帮助你了解你的 app 是由什么决定的：
- (id)init {
self = [super init];
if (self != nil) {
NSString *label = [NSString stringWithFormat:@"%@.isolation.%p", [self class], self];
self.isolationQueue = dispatch_queue_create([label UTF8String], 0);
label = [NSString stringWithFormat:@"%@.work.%p", [self class], self];
self.workQueue = dispatch_queue_create([label UTF8String], 0);
}
return self;
}
队列可以是并行也可以是串行的。默认情况下，它们是串行的，也就是说，任何给定的时间内，只能有一个单独的 block 运行。这就是隔离队列（isolation queues）的运行方式。队列也可以是并行的，也就是同一时间内允许多个 block 一起执行。
GCD 队列的内部使用的是线程。GCD 管理这些线程，并且使用 GCD 的时候，你不需要自己创建线程。但是重要的外在部分 GCD 会呈现给你，也就是用户 API，一个很大不同的抽象层级。当使用 GCD 来完成并发的工作时，你不必考虑线程方面的问题，取而代之的，只需考虑队列和功能点（提交给队列的 block）。虽然往下深究，依然都是线程，但是 GCD 的抽象层级为你惯用的编码提供了更好的方式。
队列和功能点同时解决了一个连续不断的扇出的问题：如果我们直接使用线程，并且想要做一些并发的事情，我们很可能将我们的工作分成 100 个小的功能点，然后基于可用的 CPU 内核数量来创建线程，假设是 8。我们把这些功能点送到这 8 个线程中。当我们处理这些功能点时，可能会调用一些函数作为功能的一部分。写那个函数的人也想要使用并发，因此当你调用这个函数的时候，这个函数也会创建 8 个线程。现在，你有了 8 × 8 = 64 个线程，尽管你只有 8 个CPU内核——也就是说任何时候只有12%的线程实际在运行而另外88%的线程什么事情都没做。使用
GCD 你就不会遇到这种问题，当系统关闭 CPU 内核以省电时，GCD 甚至能够相应地调整线程数量。
GCD 通过创建所谓的线程池来大致匹配 CPU 内核数量。要记住，线程的创建并不是无代价的。每个线程都需要占用内存和内核资源。这里也有一个问题：如果你提交了一个 block 给 GCD，但是这段代码阻塞了这个线程，那么这个线程在这段时间内就不能用来完成其他工作——它被阻塞了。为了确保功能点在队列上一直是执行的，GCD 不得不创建一个新的线程，并把它添加到线程池。
如果你的代码阻塞了许多线程，这会带来很大的问题。首先，线程消耗资源，此外，创建线程会变得代价高昂。创建过程需要一些时间。并且在这段时间中，GCD 无法以全速来完成功能点。有不少能够导致线程阻塞的情况，但是最常见的情况与 I/O 有关，也就是从文件或者网络中读写数据。正是因为这些原因，你不应该在GCD队列中以阻塞的方式来做这些操作。看一下下面的输入输出段落去了解一些关于如何以 GCD 运行良好的方式来做 I/O 操作的信息。
目标队列:
你能够为你创建的任何一个队列设置一个目标队列。这会是很强大的，并且有助于调试。
为一个类创建它自己的队列而不是使用全局的队列被普遍认为是一种好的风格。这种方式下，你可以设置队列的名字，这让调试变得轻松许多—— Xcode 可以让你在 Debug Navigator 中看到所有的队列名字，如果你直接使用 lldb。(lldb) thread list 命令将会在控制台打印出所有队列的名字。一旦你使用大量的异步内容，这会是非常有用的帮助。
使用私有队列同样强调封装性。这时你自己的队列，你要自己决定如何使用它。
默认情况下，一个新创建的队列转发到默认优先级的全局队列中。我们就将会讨论一些有关优先级的东西。
你可以改变你队列转发到的队列——你可以设置自己队列的目标队列。以这种方式，你可以将不同队列链接在一起。你的 Foo 类有一个队列，该队列转发到 Bar 类的队列，Bar 类的队列又转发到全局队列。
当你为了隔离目的而使用一个队列时，这会非常有用。Foo 有一个隔离队列，并且转发到 Bar 的隔离队列，与 Bar 的隔离队列所保护的有关的资源，会自动成为线程安全的。
如果你希望多个 block 同时运行，那要确保你自己的队列是并发的。同时需要注意，如果一个队列的目标队列是串行的（也就是非并发），那么实际上这个队列也会转换为一个串行队列。
优先级：
你可以通过设置目标队列为一个全局队列来改变自己队列的优先级，但是你应该克制这么做的冲动。
在大多数情况下，改变优先级不会使事情照你预想的方向运行。一些看起简单的事情实际上是一个非常复杂的问题。你很容易会碰到一个叫做优先级反转的情况。
此外，使用 DISPATCH_QUEUE_PRIORITY_BACKGROUND 队列时，你需要格外小心。除非你理解了 throttled I/O 和 background status as per setpriority(2) 的意义，否则不要使用它。不然，系统可能会以难以忍受的方式终止你的 app 的运行。打算以不干扰系统其他正在做 I/O 操作的方式去做 I/O 操作时，一旦和优先级反转情况结合起来，这会变成一种危险的情况。
隔离：
隔离队列是 GCD 队列使用中非常普遍的一种模式。这里有两个变种。
资源保护：
多线程编程中，最常见的情形是你有一个资源，每次只有一个线程被允许访问这个资源。
我们在有关多线程技术的文章中知道资源在并发编程中意味着什么，它通常就是一块内存或者一个对象，每次只有一个线程可以访问它。
举例来说，我们需要以多线程（或者多个队列）方式访问 NSMutableDictionary 。我们可能会照下面的代码来做：
- (void)setCount:(NSUInteger)count forKey:(NSString *)key{
key = [key copy];
dispatch_async(self.isolationQueue, ^(){
if (count == 0) {
[self.counts removeObjectForKey:key];
} else {
self.counts[key] = @(count);
}
});
}
- (NSUInteger)countForKey:(NSString *)key{
__block NSUInteger count;
dispatch_sync(self.isolationQueue, ^(){
NSNumber *n = self.counts[key];
count = [n unsignedIntegerValue];
});
return count;
}
通过以上代码，只有一个线程可以访问 NSMutableDictionary 的实例。
注意以下四点：
1、不要使用上面的代码，请先阅读多读单写和锁竞争
2、我们使用 async 方式来保存值，这很重要。我们不想也不必阻塞当前线程只是为了等待写操作完成。当读操作时，我们使用 sync 因为我们需要返回值。
3、从函数接口可以看出，-setCount:forKey: 需要一个 NSString 参数，用来传递给 dispatch_async。函数调用者可以自由传递一个 NSMutableString 值并且能够在函数返回后修改它。因此我们必须对传入的字符串使用 copy 操作以确保函数能够正确地工作。如果传入的字符串不是可变的（也就是正常的 NSString 类型），调用copy基本上是个空操作。
4、isolationQueue 创建时，参数 dispatch_queue_attr_t 的值必须是DISPATCH_QUEUE_SERIAL（或者0）。
单一资源的多读单写：
我们能够改善上面的那个例子。GCD 有可以让多线程运行的并发队列。我们能够安全地使用多线程来从 NSMutableDictionary 中读取只要我们不同时修改它。当我们需要改变这个字典时，我们使用 barrier 来分发这个 block。这样的一个 block 的运行时机是，在它之前所有计划好的 block 完成之后，并且在所有它后面的 block 运行之前。
以如下方式创建队列：
self.isolationQueue = dispatch_queue_create([label UTF8String], DISPATCH_QUEUE_CONCURRENT);
然后重写setter函数：
- (void)setCount:(NSUInteger)count forKey:(NSString *)key{
key = [key copy];
dispatch_barrier_async(self.isolationQueue, ^(){
if (count == 0) {
[self.counts removeObjectForKey:key];
} else {
self.counts[key] = @(count);
}
});
}
当使用并发队列时，要确保所有的 barrier 调用都是 async 的。如果你使用 dispatch_barrier_sync ，那么你很可能会使你的代码产生死锁。写操作需要 barrier，并且可以是 async 的。
锁竞争：
首先，这里有一个警告：上面这个例子中我们保护的资源是一个 NSMutableDictionary，出于这样的目的，这段代码运行地相当不错。但是在真实的代码中，把隔离放到正确的复杂度层级下是很重要的。
如果你对 NSMutableDictionary 的访问操作变得非常频繁，你会碰到一个已知的叫做锁竞争的问题。锁竞争并不是只是在 GCD 和队列下才变得特殊，任何使用了锁机制的程序都会碰到同样的问题——只不过不同的锁机制会以不同的方式碰到。
所有对 dispatch_async，dispatch_sync 等等的调用都需要完成某种形式的锁——以确保仅有一个线程或者特定的线程运行指定的代码。GCD 某些程序上可以使用时序(译注：原词为 scheduling)来避免使用锁，但在最后，问题只是稍有变化。根本问题仍然存在：如果你有大量的线程在相同时间去访问同一个锁或者队列，你就会看到性能的变化。性能会严重下降。
你应该从直接复杂层次中隔离开。当你发现了性能下降，这明显表明代码中存在设计问题。这里有两个开销需要你来平衡。第一个是独占临界区资源太久的开销，以至于别的线程都因为进入临界区的操作而阻塞。第二个是太频繁出入临界区的开销。在 GCD 的世界里，第一种开销的情况就是一个 block 在隔离队列中运行，它可能潜在的阻塞了其他将要在这个隔离队列中运行的代码。第二种开销对应的就是调用 dispatch_async 和 dispatch_sync 。无论再怎么优化，这两个操作都不是无代价的。
令人忧伤的，不存在通用的标准来指导如何正确的平衡，你需要自己评测和调整。启动 Instruments 观察你的 app 忙于什么操作。
如果你看上面例子中的代码，我们的临界区代码仅仅做了很简单的事情。这可能是也可能不是好的方式，依赖于它怎么被使用。
在你自己的代码中，要考虑自己是否在更高的层次保护了隔离队列。举个例子，类 Foo 有一个隔离队列并且它本身保护着对 NSMutableDictionary 的访问，代替的，可以有一个用到了 Foo 类的 Bar 类有一个隔离队列保护所有对类 Foo 的使用。换句话说，你可以把类 Foo 变为非线程安全的（没有隔离队列），并在 Bar 中，使用一个隔离队列来确保任何时刻只能有一个线程使用 Foo 。
全部使用异步分发：
正如你在上面看到的，你可以同步和异步地分发一个 block，一个工作单元。但是我们需要正视一个一个非常普遍的问题——死锁。在 GCD 中，以同步分发的方式非常容易出现这种情况。见下面的代码：
dispatch_queue_t queueA; // assume we have this
dispatch_sync(queueA, ^(){
dispatch_sync(queueA, ^(){
foo();
});
});
一旦我们进入到第二个 dispatch_sync 就会发生死锁。我们不能分发到queueA，因为当前线程正在队列中并且永远不会离开。但是有更隐晦的产生死锁方式：
dispatch_queue_t queueA; // assume we have this
dispatch_queue_t queueB; // assume we have this
dispatch_sync(queueA, ^(){
foo();
});
void foo(void){
dispatch_sync(queueB, ^(){
bar();
});
}
void bar(void){
dispatch_sync(queueA, ^(){
baz();
});
}
单独的每次调用 dispatch_sync() 看起来都没有问题，但是一旦组合起来，就会发生死锁。
这是使用同步分发存在的固有问题，如果我们使用异步分发，比如：
dispatch_queue_t queueA; // assume we have this
dispatch_async(queueA, ^(){
dispatch_async(queueA, ^(){
foo();
});
});
一切运行正常。异步调用不会产生死锁。因此值得我们在任何可能的时候都使用异步分发。我们使用一个异步调用结果 block 的函数，来代替编写一个返回值（必须要用同步）的方法或者函数。这种方式，我们会有更少发生死锁的可能性。
异步调用的副作用就是它们很难调试。当我们在调试器里中止代码运行，回溯并查看已经变得没有意义了。
要牢记这些。死锁通常是最难处理的问题。
如何写出好的异步API（重点）：
如果你正在给设计一个给别人（或者是给自己）使用的 API，你需要记住几种好的实践。
正如我们刚刚提到的，你需要倾向于异步 API。当你创建一个 API，它会在你的控制之外以各种方式调用，如果你的代码能产生死锁，那么死锁就会发生。
如果你需要写的函数或者方法，那么让它们调用 dispatch_async() 。不要让你的函数调用者来这么做，这个调用应该在你的方法或者函数中来做。
如果你的方法或函数有一个返回值，异步地将其传递给一个回调处理程序。这个 API 应该是这样的，你的方法或函数同时持有一个结果 block 和一个将结果传递过去的队列。你函数的调用者不需要自己来做分发。这么做的原因很简单：几乎所有时间，函数调用都应该在一个适当的队列中，而且以这种方式编写的代码是很容易阅读的。总之，你的函数将会（必须）调用 dispatch_async() 去运行回调处理程序，所以它同时也可能在需要调用的队列上做这些工作。
如果你写一个类，让你类的使用者设置一个回调处理队列或许会是一个好的选择。你的代码可能像这样：
- (void)processImage:(UIImage *)image completionHandler:(void(^)(BOOL success))handler{
dispatch_async(self.isolationQueue, ^(void){
// do actual processing here
dispatch_async(self.resultQueue, ^(void){
handler(YES);
});
});
}
如果你以这种方式来写你的类，让类之间协同工作就会变得容易。如果类 A 使用了类 B，它会把自己的隔离队列设置为 B 的回调队列。