摘抄自 ： http://www.cocoachina.com/industry/20140428/8248.html
http://www.cocoachina.com/industry/20140515/8433.html
Serial vs. Concurrent 串行 vs. 并发
为任务间关系，串行为每一次只有一个任务被执行，下一个任务需等当前任务完成后才被执行。
并发为在同一时间可以有多个任务被执行。
并行要求并发，但并发并不能保证并行。因为并发要在多核的物理前提下，单核的时候一次只能执行一个线程，但是通过上下文很快的切换就能假装一次执行多个线程从而在假装并发。
Synchronous vs. Asynchronous 同步 vs. 异步
为任务内关系，同步为当前任务执行完成后才返回，会阻塞当前线程。
异步为当前任务会完成但是不会等到执行完才返回，不会阻塞当前线程。
Serial Queues 串行队列
队列中的任务保证按顺序执行，一次执行一个任务，当前任务执行完成后再执行下一个任务。所以不存在两个任务同时访问同一个变量从而造成临界区的安全问题。
Concurrent Queues 并发队列
队列只保证任务按照添加的顺序依次执行，但是不能保证每个人物的完成顺序。每个任务的开始时间及当前在执行的任务数量未知。
系统提供的全局队列
主队列（main queue）：串行队列，用于UI刷新
全局调度队列（Global Dispatch Queues）： 并发队列
优先级：background、low、default 以及 high
Apple 的 API 也会使用这些队列，所以你添加的任何任务都不会是这些队列中唯一的任务。
自定义队列
dispatch_queue_t queue = dispatch_queue_create("queue_custom_name", NULL);
第一个参数为队列名标示，自定义。
第二个为自定义队列类型，NULL为默认创建串行队列，同DISPATCH_QUEUE_SERIAL
DISPATCH_QUEUE_CONCURRENT为创建并发队列。
------------------------------------------------------------------------------------------------------
使用情况
dispatch_async：异步提交任务到队列
1. 自定义串行队列：当你想串行执行后台任务并追踪它时就是一个好选择。这消除了资源争用，因为你知道一次只有一个任务在执行。注意若你需要来自某个方法的数据，你必须内联另一个 Block 来找回它或考虑使用 dispatch_sync。
2. 主队列（串行）：这是在一个并发队列上完成任务后更新 UI 的共同选择。要这样做，你将在一个 Block 内部编写另一个 Block 。以及，如果你在主队列调用 dispatch_async 到主队列，你能确保这个新任务将在当前方法完成后的某个时间执行。
3. 并发队列：这是在后台执行非 UI 工作的共同选择。
dispatch_sync：同步提交任务到队列并在返回前等待它完成
1. 自定义串行队列：在这个状况下要非常小心！如果你正运行在一个队列并调用 dispatch_sync 放在同一个队列，那你就百分百地创建了一个死锁。
2. 主队列（串行）：同上面的理由一样，必须非常小心！这个状况同样有潜在的导致死锁的情况。
3. 并发队列：这才是做同步工作的好选择，不论是通过调度障碍，或者需要等待一个任务完成才能执行进一步处理的情况。
dispatch_after：延后执行
工作起来就像一个延迟版的 dispatch_async 。你依然不能控制实际的执行时间，且一旦 dispatch_after 返回也就不能再取消它。
1. 自定义串行队列：在一个自定义串行队列上使用 dispatch_after 要小心。你最好坚持使用主队列。
2. 主队列（串行）：是使用 dispatch_after 的好选择；Xcode 提供了一个不错的自动完成模版。
3. 并发队列：在并发队列上使用 dispatch_after 也要小心；你会这样做就比较罕见。还是在主队列做这些操作吧。
dispatch_once：保证block中代码只执行一次
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
//create a singleton
});
dispatch_barriers:
在并发队列上工作时扮演一个串行式的瓶颈。使用 GCD 的障碍（barrier）API 确保提交的 Block 在那个特定时间上是指定队列上唯一被执行的条目。这就意味着所有的先于调度障碍提交到队列的条目必能在这个 Block 执行前完成。
1. 自定义串行队列：一个很坏的选择；障碍不会有任何帮助，因为不管怎样，一个串行队列一次都只执行一个操作。
2. 全局并发队列：要小心；这可能不是最好的主意，因为其它系统可能在使用队列而且你不能垄断它们只为你自己的目的。
3. 自定义并发队列：这对于原子或临界区代码来说是极佳的选择。任何你在设置或实例化的需要线程安全的事物都是使用障碍的最佳候选。
------------------------------------------------------------------------------------------------------
Dispatch_Groups（调度组）
会在整个组的任务都完成时通知你。这些任务可以是同步的，也可以是异步的，即便在不同的队列也行。而且在整个组的任务都完成时，Dispatch Group 可以用同步的或者异步的方式通知你。因为要监控的任务在不同队列，那就用一个 dispatch_group_t 的实例来记下这些不同的任务。
当组中所有的事件都完成时，GCD 的 API 提供了两种通知方式:
dispatch_group_wait
使用流程：
1.会阻塞当前线程，直到组里面所有的任务都完成或者等到某个超时发生,所以要用 dispatch_async 将整个方法放入后台队列以避免阻塞主线程;
2.创建一个新的dispatch_group_t实例，作用类似未完成任务计数器，手动dispatch_group_enter，执行任务，手动dispatch_group_leave;
3.必须保证 dispatch_group_enter 和 dispatch_group_leave 成对出现，否则你可能会遇到诡异的崩溃问题。
4. dispatch_group_wait 会一直等待，直到任务全部完成或者超时。如果在所有任务完成前超时了，该函数会返回一个非零值。可规定它的等待超时时间，DISPATCH_TIME_FOREVER为永远等待。
5.回调主线程
适用情况：
1. 自定义串行队列：它很适合当一组任务完成时发出通知。
2. 主队列（串行）：它也很适合这样的情况。但如果你要同步地等待所有工作地完成，那你就不应该使用它，因为你不能阻塞主线程。然而，异步模型是一个很有吸引力的能用于在几个较长任务（例如网络调用）完成后更新 UI 的方式。
3. 并发队列：它也很适合 Dispatch Group 和完成时通知
dispatch_group_notify：
1.不会阻塞当前线程，所以不用放在dispatch_async中实现
2.同样需要手动dispatch_group_enter、dispatch_group_leave。
3.以异步的方式工作。当 Dispatch Group 中没有任何任务时，它就会执行其代码。
------------------------------------------------------------------------------------------------------
dispatch_apply
并发执行，同步返回。第一次参数指明了迭代的次数，用第二个参数指定了任务运行的队列，而第三个参数是一个 Block
1. 自定义串行队列：串行队列会完全抵消 dispatch_apply 的功能；你还不如直接使用普通的 for 循环。
2. 主队列（串行）：与上面一样，在串行队列上不适合使用 dispatch_apply 。还是用普通的 for 循环吧。
3. 并发队列：对于并发循环来说是很好选择，特别是当你需要追踪任务的进度时
网友评论