这篇文章非常详细的介绍了iOS中的GCD相关知识，并且结合具体实例进行了分析。

感兴趣的朋友可以看看原文，在这里我总结和翻译了我个人认为比较精华的部分。

预备知识

顺序与并发（serial vs concurrent）

顺序执行指在同一时间只有一个任务被执行；并发则指任务可能会同时被执行。

任务（tasks）

在本文中，一个任务可以被认为就是一个闭包。实际上，你同样可以用函数指针进行GCD操作，但是这种用法会非常复杂。闭包则会非常简单。

不知道什么是闭包（closure）的自己去百度。

同步与异步

这两个术语描述了一个方法何时会把控制权返回给调用者，还有在那之前会干些什么事情。

同步方法只有在任务完成后才会把控制权返回给调用者。

异步方法则会立即返回，不会等待它完成。也就是说异步方法不会阻塞当前线程执行下一个方法。

还有一些概念比较常见如，race condition，死锁，线程安全，上下文切换等，可自行百度。

并发与平行（Concurrency vs Parallelism）

这两个概念通常会被一同提到。

不同的并发代码可以“同时”被执行。不过，这取决与系统如何实现--或者压根就不实现。

多核的设备可以真正意义上的同时执行多个线程，不过对于单核设备要实现并发，就必须要首先实现上下文切换。上下文切换通常是非常迅速的，因此给用户了一个并发的假象。

队列

GCD提供了dispatch queues来处理提交的任务，这些队列都是FIFO的。所有的dispatch queues自身都是线程安全的。当你知道了如何选择正确的dispatch queue和dispatch function，你就可以很好的理解GCD的带来的好处。

顺序队列

在顺序队列中的任务同一时间只执行一个，后面的任务只有在前一任务完成后才能被启动。同样的，你不能确定下一个任务的启动时间和上一个任务的结束时间之间的间隔。如下图所示：

由此可知，顺序队列中的任务都是线程安全的，因为他们不可能同时访问临界区。

并发队列

并发队列中的任务只能保证他们的启动时间和他们入队的时间一致。如下图：

队列和线程

队列和线程是不同的东西。队列只是用来管理任务的执行顺序，是否并发和优先级。任务都是运行在线程上的，GCD是用线程池实现的，你不用自己来维护线程池。不过，你需要意识到一些系统队列比如main queue和global queue。他们都有一些特殊的属性并且被iOS系统使用。比如main queue是一个和主线程绑定的顺序队列。

队列类型

1.主队列（main queue）

主队列是一个顺序队列，他可以保证所有的任务都在主线程中执行。主线程是唯一一个可以更新UI的线程。

2.全局队列

全局队列是一个并发队列和下面的各种QoS一起使用，注意全局队列中可能已经有其他的任务，所以除了你添加的任务，有可能还有其他任务在队列中。

3.并发队列

GCD还提供了一系列的同步队列。这些队列都和各自的QoS类进行绑定。这些不同的QoS类表明了该队列的用途，以此来帮助GCD进行优化：

QOS_CLASS_USER_INteraCTIVE：该队列中的任务需要立即执行以保证良好的用户体验。在进行UI更新，事件处理和低负荷小延迟的任务时使用这个队列。
QOS_CLASS_USER_INITIATED：这个类代表那些由UI发起的任务，同时这些任务又可以被异步处理。当用户需要任务立即返回以进行后续互动的时候，用这个队列。
QOS_CLASS_USER_UTILITY:这个类代表长时间运行的任务，通常会伴有用户可见的进度条。在复杂运算，IO，网络，连续数据传输时使用这个队列。
QOS_CLASS_USER_BACKGROUND：后台运行非时间敏感的任务所使用

dispatch_async

把任务添加到对应队列并立即返回。适用于基于网络或者高负荷cpu任务。

自定义顺序队列（custom serial queue）：适用于后台顺序执行工作。排除了资源竞争问题，如需要获得结果需要内嵌闭包来获取或者使用dispatch_sync。
主队列（main queue）：主要用于更新UI，需要内嵌于其他闭包中。如果你在main queue中调用 dispatch_async把任务添加到main queue中，那么你可以确保新的任务会在当前方法结束后被执行。
并发队列（concurrent queue）：通常用于后台处理。

dispatch_sync

把任务添加到对应队列并等待其完成后再继续执行当前任务，容易造成死锁，或阻塞当前任务。

自定义顺序队列（custom serial queue）：谨慎使用。如果你在一个队列中使用dispatch_sync把任务提交到同一个队列，那么会造成死锁
主队列（main queue）:同理，谨慎使用。
并发队列（concurrent queue）：最好的候选者。

dispatch_barrier_async

一般需要首先使用dispatch_queue_create来创建自定义队列，然后使用。在并发队列中以顺序执行的方式完成任务。

自定义顺序队列（custom serial queue）：不好的选择，因为不会带来任何好处。
全局并发队列（global concurrent queue）:谨慎使用，因为barrier会阻塞队列，该队列可能还有其他任务。
自定义并发队列（custom concurrent queue）：最好的候选者。

dispatch_after

指定时间后把任务添加到队列中。效果就像是延时后的dispatch_async。

单例模式中的线程安全

在swift中，所有全局变量的初始化都是线程安全的。在swift中，全局变量在首次被访问的时候进行初始化，并且初始化是一个原子过程。因为swift在初始化全局变量的时候使用了dispatch_once。这个方法确保了任务以线程安全的方式被执行一次。

初始化解决了，但是读写同步的问题还没有解决。

看如下代码：

func addPhoto(photo: Photo) {
  _photos.append(photo)
  dispatch_async(dispatch_get_main_queue()) {
    self.postContentAddednotification()
  }
}

这是一个写操作

private var _photos: [Photo] = []
var photos: [Photo] {
  return _photos
}

这是一个读操作

当一个线程在调用写操作的同时，如果另一个线程调用读操作，就会出现问题。

注：在swift中class的传递是引用传递（pass-by-reference），enum和struct是值传递（pass-by-value）。而array和dictionary在swift中是以struct的形式实现的，所以以上的读操作返回的是一个副本。

其实，这就是经典的读者-作者问题。在GCD中使用dispatch barrier来解决这个问题。

dispatch barrier是一组方法，它们都已顺序化的方式来结合同步队列进行工作。使用barrier的API确保了在特定时间同一队列中仅有被barrier提交的任务被执行。如下图所示：

使用dispatch barrier，首先需要手动建立一个队列：

private let concurrentPhotoQueue = dispatch_queue_create(
    "com.raywenderlich.GooglyPuff.photoQueue",disPATCH_QUEUE_CONCURRENT)

第一个参数是队列的标示，第二个参数表明该队列是并发还是顺序执行。

然后修改写操作如下:

func addPhoto(photo: Photo) {
  dispatch_barrier_async(concurrentPhotoQueue) { // 1
    self._photos.append(photo) // 2
    dispatch_async(GlobalMainQueue) { // 3
      self.postContentAddednotification()
    }
  }
}

写操作搞定了，接下来要搞定读操作.

为了保证线程安全，你需要在concurrentPhotoQueue上进行读操作。并且必须要等待任务返回后，读操作才能返回，所以不能使用dispatch_async。

在这种情况下应该使用dispatch_sync。dispatch_sync把任务提交到队列中人后等待它完成后才返回。一般情况下，dispatch_sync都是与dispatch_barrier一起使用的。

使用这个函数要相当小心。设想一下如果你用dispatch_sync在当前队列中添加任务的话，那么就会造成死锁。这就迫使你明确你调用的队列是什么和你提交的队列是什么。

修改后的读操作如下：

var photos: [Photo] {
  var photoscopy: [Photo]!
  dispatch_sync(concurrentPhotoQueue) { // 1
    photoscopy = self._photos // 2
  }
  return photoscopy
}

【荐】Grand Central Dispatch Tutorial for Swift: Part 1/2