iOS开发：深入理解GCD 第二篇（dispatch_group、dispatch_barrier、基于线程安全的多读单写）

iOS开发：深入理解GCD 第二篇（dispatch_group、dispatch_barrier、基于线程安全的多读单写）

Dispatch Group

在追加到Dispatch Queue中的多个任务处理完毕之后想执行结束处理，这种需求会经常出现。如果只是使用一个Serial Dispatch Queue（串行队列）时，只要将想执行的处理全部追加到该串行队列中并在最后追加结束处理即可，但是在使用Concurrent Queue 时，可能会同时使用多个Dispatch Queue时，源代码就会变得很复杂。

在这种情况下，就可以使用Dispatch Group。

控制台的输出：





因为向Concurrent Dispatch Queue 追加处理，多个线程并行执行，所以追加处理的执行顺序不定。执行顺序会发生变化，但是此执行结果的done一定是最后输出的。

无论向什么样的Dispatch Queue中追加处理，使用Dispatch Group都可以监视这些处理执行的结果。一旦检测到所有处理执行结束，就可以将结束的处理追加到Dispatch Queue中，这就是使用Dispatch Group的原因。

下面试一个使用Dispatch Group异步下载两张图片，然后合并成一张图片的medo（注意，我们总是应该在主线程中更新UI）：

dispatch_barrier_async

在访问数据库或者文件的时候，我们可以使用Serial Dispatch Queue可避免数据竞争问题，代码如下所示：

先看看，如果我们在平常编码中，如果要保证某个属性可以线程安全的读写，如何写的：

这是我在刚学iOS开发，刚涉及并发中的数据竞争时，书本上提到的一种解决方案。如果有多个线程要执行同一份代码，那么有时候可能会出现问题，这种情况下，通常要使用锁来实现某种同步机制。iOS提供了一种加锁的方式，就是采用内置的synchronization block，也就是上面代码所写的。
这种写法会根据给定的对象，自动创建一个锁，并等待块中的代码执行完毕。执行到这段代码结尾处，锁也就释放了。在上面的例子中，同步行为所针对的对象是self。这么写通常没错，但是@synchronized(self)会大大降低代码效率，甚至很多时候，还可以被人感觉到效率明显下降了，因为共用同一个锁的那些同步块，都必须按顺序执行。若在self对象上频繁加锁，那么程序可能就要等另一段与此无关的代码执行完毕，才可以继续执行当前代码，这样做是很没必要的。

@synchronized(self)会大大降低代码效率，因为所有的同步块（ @synchronized(self) ）都会彼此抢夺同一个锁。要是有多个属性这么写，每个属性的同步块（ @synchronized(self) ）都要等其他所有的同步块执行完毕之后才能执行，这并不是我们想要的结果，我们只想要每个属性各自独立的同步。

还有，不得不说，按上面这么做，虽然可以在一定程度上提供“线程安全”，但却无法保证访问该对象时是绝对线程安全的。事实上，上面的写法，就是atomic，也就是原子性属性xcode自动生成的代码，这种方法，在访问属性时，必定可以从中得到有效值，然而如果在一个线程上多次调用getter方法，每次得到的结果却未必相同，在两次读操作之间，其他线程可能会写入新的属性值。

其实使用GCD可以简单高效的代替同步块或者锁对象，可以使用，串行同步队列，将读操作以及写操作都安排在同一个队列里，即可保证数据同步，代码如下：

这样写的思路是：把写操作与读操作都安排在同一个同步串行队列里面执行，这样的话，所有针对属性的访问操作就都同步了。

这种方法的确已经足够好了，但还不是最优的，它只可以实现单读、单写。整体来看，我们最终要解决的问题是，在写的过程中不能被读，以免数据不对，但是读与读之间并没有任何的冲突！

多个getter方法（也就是读取）是可以并发执行的，而getter(读)与setter（写）方法是不能并发执行的，利用这个特点，还能写出更快的代码来，这次注意，不用串行队列，而改用并行队列：

这样优化，测试一下性能，可以发现这种做法肯定比使用串行队列要快。

在这个代码中，我用了点新的东西，dispatch_barrier_async，可以翻译成栅栏（barrier），它可以往队列里面发送任务（块，也就是block），这个任务有栅栏（barrier）的作用。

在队列中，barrier块必须单独执行，不能与其他block并行。这只对并发队列有意义，并发队列如果发现接下来要执行的block是个barrier block，那么就一直要等到当前所有并发的block都执行完毕，才会单独执行这个barrier block代码块，等到这个barrier block执行完毕，再继续正常处理其他并发block。在上面的代码中，setter方法中使用了barrier block以后，对象的读取操作依然是可以并发执行的，但是写入操作就必须单独执行了。

附录（也算是追加）

也许会对并行、串行、异步、同步有所理解不深。

并行：就是队列里面的任务（代码块，block）不是一个个执行，而是并发执行，也就是可以同时执行的意思

串行：队列里面的任务一个接着一个执行，要等前一个任务结束，下一个任务才可以执行

异步：具有新开线程的能力

同步：不具有新开线程的能力，只能在当前线程执行任务

那么，如果他们相互串起来，会怎么样呢？

并行+异步：就是真正的并发，新开有有多个线程处理任务，任务并发执行（不按顺序执行）

串行+异步：新开一个线程，任务一个接一个执行，上一个任务处理完毕，下一个任务才可以被执行

并行+同步：不新开线程，任务一个接一个执行

串行+同步：不新开线程，任务一个接一个执行

如此，并行+异步，串行+异步倒是很好辨别，他们有各自的特点，那么并行+同步，串行+同步，貌似效果是一样的，好像用哪种都一样？？！！

不，这其中区别很大（不得不说一句，我所看多线程书籍，基本没讲到这点的，不知道是不是他们都认为这是基础，没必要说明）。

这其中的区别，我觉得代码体现更直观，直接上代码吧：

这一份是串行+同步，我在外面并发添加代码块：

看看打印：





在一个线程里面，任务一个接一个的执行。

再看看，并行+同步，并发调用：

打印：




新开了多个线程，任务并发执行。

至此，难道可以说，我之前的所说的

并行+同步：不新开线程，任务一个接一个执行

串行+同步：不新开线程，任务一个接一个执行

是错的？不，并没有错，只是这种说法，是将任务添加到这种模式的内部。

朋友们，虽然这个世界日益浮躁起来，只要能够为了当时纯粹的梦想和感动坚持努力下去，不管其它人怎么样，我们也能够保持自己的本色走下去。