dispatch_barrier的来源

通过上一篇文章GCD(一) 队列、任务、串行、并发的讲解，我们了解到，并发队列可以让你追加到队列的block并发执行，而不需要等待前面入队的block完成运行。但是这样又会引发一个问题，如果并发队列允许所有的block同时执行，那么他们为什么被称为队列（FIFO）呢，它不更像一个可以加入并发执行block的堆吗？

针对上面的问题，GCD中提供了Dispatch_barrier系统的API，俗称栅栏,使用dispatch_barrier_sync()或者dispatch_barrier_async()入队的block,会等到所有的之前入队的block执行完成后才开始执行。除此之外，在barrier block后面入队的所有的block，会等到到barrier block本身已经执行完成之后才继续执行。它就像我们平时早上上班挤地铁限流的样子，一位地铁工作人员拿着一个指示牌，表示在他排在之前的人流（无序并行）进站之后，他之后的人流才可以进站。就是因为这个栅栏，并发队列的行为看起来就像队列了。

测试代码在这

dispatch_barrier_async

/*!
 * @functiongroup Dispatch Barrier API
 * The dispatch barrier API is a mechanism for submitting barrier blocks to a
 * dispatch queue, analogous to the dispatch_async()/dispatch_sync() API.
 * It enables the implementation of efficient reader/writer schemes.
 * Barrier blocks only behave specially when submitted to queues created with
 * the DISPATCH_QUEUE_CONCURRENT attribute; on such a queue, a barrier block
 * will not run until all blocks submitted to the queue earlier have completed,
 * and any blocks submitted to the queue after a barrier block will not run
 * until the barrier block has completed.
 * When submitted to a a global queue or to a queue not created with the
 * DISPATCH_QUEUE_CONCURRENT attribute, barrier blocks behave identically to
 * blocks submitted with the dispatch_async()/dispatch_sync() API.
 */

/*!
 * @function dispatch_barrier_async
 *
 * @abstract
 * Submits a barrier block for asynchronous execution on a dispatch queue.
 *
 * @discussion
 * Submits a block to a dispatch queue like dispatch_async(), but marks that
 * block as a barrier (relevant only on DISPATCH_QUEUE_CONCURRENT queues).
 *
 * See dispatch_async() for details.
 *
 * @param queue
 * The target dispatch queue to which the block is submitted.
 * The system will hold a reference on the target queue until the block
 * has finished.
 * The result of passing NULL in this parameter is undefined.
 *
 * @param block
 * The block to submit to the target dispatch queue. This function performs
 * Block_copy() and Block_release() on behalf of callers.
 * The result of passing NULL in this parameter is undefined.
 */

从它的官方注释中我们可以知道：

dispatch_barrier 是一个类似于dispatch_async()/dispatch_sync()的API，它可以将barrier block提交到队列中，barrier block 只有提交到自定义的并发队列中才能真正的当做一个栅栏,它在这里起到一个承上启下的作用，只有比它（barrier block）先提交到自定义并发队列的block全部执行完成，它才会去执行，等它执行完成，在它之后添加的block才会继续往下执行。

当dipatch_barrier block没有被提交到自定义的串行队列中，它与dispatch_async()/dispatch_sync()的作用是一样的。

我们通过一些代码去验证一下：

##pragma mark - dispatch_barrier_async + 自定义并发队列
/*
 * 特点：
 * 1.barrier之前的任务并发执行，barrier之后的任务在barrier任务完成之后并发执行
 * 2.会开启新线程执行任务
 * 3.不会阻塞当前线程（主线程）
 */
- (IBAction)executeBarrierAsyncCustomConcurrentQueueTask:(UIButton *)sender {
    
    NSLog(@"CurrentThread---%@",[NSThread currentThread]);  // 打印当前线程
    NSLog(@"---begin---");
    
    NSLog(@"追加任务1");
    dispatch_async(self.concurrentQueue, ^{
        // 追加任务1
        for (int i = 0; i < 2; ++i) {
            [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
            NSLog(@"1---%@",[NSThread currentThread]);      // 打印当前线程
        }
    });
    
    NSLog(@"追加任务2");
    dispatch_async(self.concurrentQueue, ^{
        // 追加任务2
        for (int i = 0; i < 2; ++i) {
            [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
            NSLog(@"2---%@",[NSThread currentThread]);      // 打印当前线程
        }
    });
    
    NSLog(@"追加barrier_async任务");
    dispatch_barrier_async(self.concurrentQueue, ^{
        // 追加barrier任务
        for (int i = 0; i < 2; ++i) {
            [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
            NSLog(@"barrier---%@",[NSThread currentThread]);      // 打印当前线程
        }
    });
    
    NSLog(@"追加任务3");
    dispatch_async(self.concurrentQueue, ^{
        // 追加任务3
        for (int i = 0; i < 2; ++i) {
            [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
            NSLog(@"3---%@",[NSThread currentThread]);      // 打印当前线程
        }
    });
    
    NSLog(@"追加任务4");
    dispatch_async(self.concurrentQueue, ^{
        // 追加任务4
        for (int i = 0; i < 2; ++i) {
            [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
            NSLog(@"4---%@",[NSThread currentThread]);      // 打印当前线程
        }
    });
    
    NSLog(@"---end---");
    NSLog(@"*********************************************************");
}

执行结果如下：

2019-04-23 16:14:35.900776+0800 GCD(二) dispatch_barrier[18819:3551551] CurrentThread---<NSThread: 0x600002b76980>{number = 1, name = main}
2019-04-23 16:14:35.900984+0800 GCD(二) dispatch_barrier[18819:3551551] ---begin---
2019-04-23 16:14:35.901171+0800 GCD(二) dispatch_barrier[18819:3551551] 追加任务1
2019-04-23 16:14:35.901355+0800 GCD(二) dispatch_barrier[18819:3551551] 追加任务2
2019-04-23 16:14:35.901596+0800 GCD(二) dispatch_barrier[18819:3551551] 追加barrier_async任务
2019-04-23 16:14:35.901789+0800 GCD(二) dispatch_barrier[18819:3551551] 追加任务3
2019-04-23 16:14:35.902093+0800 GCD(二) dispatch_barrier[18819:3551551] 追加任务4
2019-04-23 16:14:35.902378+0800 GCD(二) dispatch_barrier[18819:3551551] ---end---
2019-04-23 16:14:35.902644+0800 GCD(二) dispatch_barrier[18819:3551551] *********************************************************
2019-04-23 16:14:37.904283+0800 GCD(二) dispatch_barrier[18819:3551647] 1---<NSThread: 0x600002b11bc0>{number = 3, name = (null)}
2019-04-23 16:14:37.904283+0800 GCD(二) dispatch_barrier[18819:3552871] 2---<NSThread: 0x600002b11cc0>{number = 4, name = (null)}
2019-04-23 16:14:39.909809+0800 GCD(二) dispatch_barrier[18819:3551647] 1---<NSThread: 0x600002b11bc0>{number = 3, name = (null)}
2019-04-23 16:14:39.909810+0800 GCD(二) dispatch_barrier[18819:3552871] 2---<NSThread: 0x600002b11cc0>{number = 4, name = (null)}
2019-04-23 16:14:41.914667+0800 GCD(二) dispatch_barrier[18819:3552871] barrier---<NSThread: 0x600002b11cc0>{number = 4, name = (null)}
2019-04-23 16:14:43.917811+0800 GCD(二) dispatch_barrier[18819:3552871] barrier---<NSThread: 0x600002b11cc0>{number = 4, name = (null)}
2019-04-23 16:14:45.921840+0800 GCD(二) dispatch_barrier[18819:3552871] 3---<NSThread: 0x600002b11cc0>{number = 4, name = (null)}
2019-04-23 16:14:45.921847+0800 GCD(二) dispatch_barrier[18819:3551647] 4---<NSThread: 0x600002b11bc0>{number = 3, name = (null)}
2019-04-23 16:14:47.927349+0800 GCD(二) dispatch_barrier[18819:3552871] 3---<NSThread: 0x600002b11cc0>{number = 4, name = (null)}
2019-04-23 16:14:47.927373+0800 GCD(二) dispatch_barrier[18819:3551647] 4---<NSThread: 0x600002b11bc0>{number = 3, name = (null)}

由此我们可以看出：

在barrier_async任务之前加入队列的任务，会在barrier任务之前并发执行，并且开辟了2条新线程去执行，barrier任务在任务1、任务2执行完成之后执行，执行完成之后，后续添加的任务才继续往下执行,并且dispatch_async并没有阻塞当前的主线程

dispatch_barrier_sync

我们将上一步的测试代码中的dispatch_barrier_async改为dispatch_barrier_sync方法去执行，得到的log如下：

2019-04-23 16:18:04.874397+0800 GCD(二) dispatch_barrier[18819:3551551] CurrentThread---<NSThread: 0x600002b76980>{number = 1, name = main}
2019-04-23 16:18:04.874601+0800 GCD(二) dispatch_barrier[18819:3551551] ---begin---
2019-04-23 16:18:04.874758+0800 GCD(二) dispatch_barrier[18819:3551551] 追加任务1
2019-04-23 16:18:04.874929+0800 GCD(二) dispatch_barrier[18819:3551551] 追加任务2
2019-04-23 16:18:04.875118+0800 GCD(二) dispatch_barrier[18819:3551551] 追加barrier_sync任务
2019-04-23 16:18:06.880055+0800 GCD(二) dispatch_barrier[18819:3552872] 1---<NSThread: 0x600002b12100>{number = 5, name = (null)}
2019-04-23 16:18:06.880102+0800 GCD(二) dispatch_barrier[18819:3562466] 2---<NSThread: 0x600002b288c0>{number = 6, name = (null)}
2019-04-23 16:18:08.885244+0800 GCD(二) dispatch_barrier[18819:3552872] 1---<NSThread: 0x600002b12100>{number = 5, name = (null)}
2019-04-23 16:18:08.885244+0800 GCD(二) dispatch_barrier[18819:3562466] 2---<NSThread: 0x600002b288c0>{number = 6, name = (null)}
2019-04-23 16:18:10.886126+0800 GCD(二) dispatch_barrier[18819:3551551] barrier---<NSThread: 0x600002b76980>{number = 1, name = main}
2019-04-23 16:18:12.887616+0800 GCD(二) dispatch_barrier[18819:3551551] barrier---<NSThread: 0x600002b76980>{number = 1, name = main}
2019-04-23 16:18:12.887776+0800 GCD(二) dispatch_barrier[18819:3551551] 追加任务3
2019-04-23 16:18:12.887907+0800 GCD(二) dispatch_barrier[18819:3551551] 追加任务4
2019-04-23 16:18:12.888021+0800 GCD(二) dispatch_barrier[18819:3551551] ---end---
2019-04-23 16:18:12.888121+0800 GCD(二) dispatch_barrier[18819:3551551] *********************************************************
2019-04-23 16:18:14.888428+0800 GCD(二) dispatch_barrier[18819:3552872] 4---<NSThread: 0x600002b12100>{number = 5, name = (null)}
2019-04-23 16:18:14.888461+0800 GCD(二) dispatch_barrier[18819:3562492] 3---<NSThread: 0x600002b29e00>{number = 7, name = (null)}
2019-04-23 16:18:16.893977+0800 GCD(二) dispatch_barrier[18819:3562492] 3---<NSThread: 0x600002b29e00>{number = 7, name = (null)}
2019-04-23 16:18:16.893977+0800 GCD(二) dispatch_barrier[18819:3552872] 4---<NSThread: 0x600002b12100>{number = 5, name = (null)}

通过log可以看到，barrier_sync与barrier_async一样，都可以在并发队列中起到栅栏的作用。但是2个方法还是有些不同的，下文中我们会详细讲解

dispatch_barrier_async与dispatch_barrier_sync的对比

通过上面的代码测试，我们可以发现，barrier_async与barrier_sync的区别仅仅在于，barrier_sync会阻塞它之后的任务的入队，必须等到barrier_sync任务执行完毕，才会把后面的异步任务添加到并发队列中，而barrier_async不需要等自身的block执行完成，就可以把后面的任务添加到队列中。

dispatch_barrier_sync与死锁

由于只有使用自定义并发队列时，dispatch_barrier方式添加的任务，才能起到栅栏的作用，添加到其它队列的情况下，dispatch_barrier_async/dispatch_barrier_sync与dispatch_async/dispatch_sync的作用是一样的，所以，当在串行队列中使用dispatch_barrier_sync时，同样的也有可能死锁，所以，我们在平常开发中要谨慎使用dispatch_barrier_sync

dispatch_barrier_async实现多读单写

假如说我们在内存维护一个字典或者是一个DB文件，有多个读者或者写者都要操作这个共享数据，我们为了实现这个多读单写的模型，就需要考虑多线程对这个数据的访问问题，我们首先要解决读者与读者应该是并发的读取，代表了多读的含义，其次呢，读者与读者应该是互斥的，比如说，有读者在读取数据的时候，就不能有些的线程去写数据，所以说，读者与写者要互斥，其次呢，写者与写者也要互斥，有一个写线程在写数据，那么另一个写线程就不能去写数据，否则会导致程序异常或者程序错乱，要满足一下三点，其实我们可以使用dispatch_barrier_async来实现多读单写

读者与读者并发
读者与写者互斥
写者与写者互斥

我们再通过一副图来看一下多读单写的具体实现流程

假如说有多个读处理同时或者并发执行的话，然后写处理需要跟读处理互斥操作，在写处理完成之后呢，然后可以再次进行读取处理，而dispatch_barrier_async正好就为我们实现了一个多读单写的模型，也就是当我们的读者在进行读处理的时候，其它的读者也可以额进行读取，但是此时，不能进行写，如果在写操作的过程中，有其它的读处理，那么这些读处理，就只能在写操作完成之后才可以执行。

我们首先定义一个类ZEDMultiReadSingleWriteHandler,然后在类中定义2个属性

/** 并发队列 */
@property (nonatomic, strong) dispatch_queue_t concurrentQueue;

/** 多读单写的数据容器，可能在不同的线程中访问 */
@property (nonatomic, strong) NSMutableDictionary *dict;

第一个属性是一个自定义的并发队列，用于使用dispatch_barrier_async的方式进行写操作。

第二个属性是一个数据存储的容器，可能会在不同的线程中访问。

在类的初始化方法里，创建并发队列与全局容器字典

- (instancetype)init {
    self = [super init];
    if (self) {
        self.concurrentQueue = dispatch_queue_create("zed.concurrent.queue", DISPATCH_QUEUE_CONCURRENT);
        self.dict = [NSMutableDictionary dictionary];
    }
    return self;
}

然后我们定义2个方法，用于给外部调用的读操作与写操作

- (id)dataForKey:(NSString *)key;
- (void)setData:(id)data forKey:(NSString *)key;

对于读操作而言，多个读操作可以并发执行，并发队列的特性就是允许提交的任务并发执行，我们这里提交的任务是通过一个key去字典中获取对象，由于这个获取操作是需要立刻同步返回结果的，所以我们要通过dispatch_sync这个函数来进行调用，同步立刻返回这个调用结果，同步到这个并发队列中，就可以允许多个线程同时读取，比如说，dataForKey这个方法可以在A线程中调用，也可以在B线程中调用，当A线程与B线程并发来访问这个同一个Key的时候，由于并发队列的性质，就可以保证他们同时并发读取某一个key的值，同时是同步调用，所以不管是哪一个线程，都可以通过这种同步方式立刻返回调用结果。
```
- (id)dataForKey:(NSString *)key {
    __block id data;
    //同步读取指定数据
    dispatch_sync(self.concurrentQueue, ^{
        data = [self.dict objectForKey:key];
    });
    return data;
}
```

写的操作就是就通过dispatch_barrier_async到一个并发队列当中去进行写，然后我们通过key把对应的值写进去

- (void)setData:(id)data forKey:(NSString *)key {
    // 异步栅栏调用设置数据
    dispatch_barrier_async(self.concurrentQueue, ^{
        [self.dict setObject:data forKey:key];
    });
}

如果文中有错误的地方，或者与你的想法相悖的地方，请在评论区告知我，我会继续改进，如果你觉得这个篇文章总结的还不错，麻烦动动小手，给我的文章与Git代码样例点个✨