118,GCD的详细理解(同步执行(sync)和异步执行(async)两者的区别是否等待队列的任务执行结束，以及是否具备开启新线程的能力，同步在指定的队列中，添加的任务执行结束之前，会一直等待，...

1. GCD 任务和队列

学习 GCD 之前，先来了解 GCD 中两个核心概念：『任务』和『队列』。
任务：就是执行操作的意思，换句话说就是你在线程中执行的那段代码。在 GCD 中是放在 block 中的。执行任务有两种方式：『同步执行』和『异步执行』。两者的主要区别是：是否等待队列的任务执行结束，以及是否具备开启新线程的能力。

同步执行（sync）：
1.同步添加任务到指定的队列中，在添加的任务执行结束之前，会一直等待，直到队列里面的任务完成之后再继续执行。
2.只能在当前线程中执行任务，不具备开启新线程的能力
异步执行（async）：
1.异步添加任务到指定的队列中，它不会做任何等待，可以继续执行任务
2.可以在新的线程中执行任务，具备开启新线程的能力

举个简单例子：你要打电话给小明和小白。
『同步执行』 就是：你打电话给小明的时候，不能同时打给小白。只有等到给小明打完了，才能打给小白（等待任务执行结束）。而且只能用当前的电话（不具备开启新线程的能力）。
『异步执行』 就是：你打电话给小明的时候，不用等着和小明通话结束（不用等待任务执行结束），还能同时给小白打电话。而且除了当前电话，你还可以使用其他一个或多个电话（具备开启新线程的能力）

注意：异步执行（async）虽然具有开启新线程的能力，但是并不一定开启新线程。这跟任务所指定的队列类型有关（下面会讲）。

队列（Dispatch Queue）：这里的队列指执行任务的等待队列，即用来存放任务的队列。队列是一种特殊的线性表，采用 FIFO（先进先出）的原则，即新任务总是被插入到队列的末尾，而读取任务的时候总是从队列的头部开始读取。每读取一个任务，则从队列中释放一个任务。队列的结构可参考下图：

118,GCD的详细理解(同步执行(sync)和异步执行(async)两者的区别是否等待队列的任务执行结束，以及是否具备开启新线程的能力，同步在指定的队列中，添加的任务执行结束之前，会一直等待，..._第1张图片

image.png

在 GCD 中有两种队列：『串行队列』 和 『并发队列』。两者都符合 FIFO（先进先出）的原则。两者的主要区别是：执行顺序不同，以及开启线程数不同。

串行队列（Serial Dispatch Queue）：
每次只有一个任务被执行。让任务一个接着一个地执行。（只开启一个线程，一个任务执行完毕后，再执行下一个任务）
并发队列（Concurrent Dispatch Queue）:
可以让多个任务并发（同时）执行。（可以开启多个线程，并且同时执行任务）

注意：并发队列的并发功能只有在异步（dispatch_async）方法下才有效。

两者具体区别如下两图所示：

118,GCD的详细理解(同步执行(sync)和异步执行(async)两者的区别是否等待队列的任务执行结束，以及是否具备开启新线程的能力，同步在指定的队列中，添加的任务执行结束之前，会一直等待，..._第2张图片

image.png

118,GCD的详细理解(同步执行(sync)和异步执行(async)两者的区别是否等待队列的任务执行结束，以及是否具备开启新线程的能力，同步在指定的队列中，添加的任务执行结束之前，会一直等待，..._第3张图片

image.png

3. GCD 的使用步骤

118,GCD的详细理解(同步执行(sync)和异步执行(async)两者的区别是否等待队列的任务执行结束，以及是否具备开启新线程的能力，同步在指定的队列中，添加的任务执行结束之前，会一直等待，..._第4张图片

截屏2020-11-11 上午9.51.02的副本.png

这个NULL 表示之前的DISPATCH_QUEUE_SERIAL

注意：添加几个任务并不是创建几个线程

截屏2020-11-25 下午1.46.55.png

118,GCD的详细理解(同步执行(sync)和异步执行(async)两者的区别是否等待队列的任务执行结束，以及是否具备开启新线程的能力，同步在指定的队列中，添加的任务执行结束之前，会一直等待，..._第5张图片

截屏2020-11-25 下午1.56.12.png

GCD 的使用步骤其实很简单，只有两步：

创建一个队列（串行队列或并发队列）；
将任务追加到任务的等待队列中，然后系统就会根据任务类型执行任务（同步执行或异步执行）。

下边来看看队列的创建方法 / 获取方法，以及任务的创建方法。

可以使用 dispatch_queue_create 方法来创建队列。该方法需要传入两个参数：
1.第一个参数表示队列的唯一标识符，用于 DEBUG，可为空。队列的名称推荐使用应用程序 ID 这种逆序全程域名。
2.第二个参数用来识别是串行队列还是并发队列。DISPATCH_QUEUE_SERIAL 表示串行队列，DISPATCH_QUEUE_CONCURRENT 表示并发队列。

// 串行队列的创建方法
dispatch_queue_t queue = dispatch_queue_create("net.bujige.testQueue", DISPATCH_QUEUE_SERIAL);
// 并发队列的创建方法
dispatch_queue_t queue = dispatch_queue_create("net.bujige.testQueue", DISPATCH_QUEUE_CONCURRENT);

对于串行队列，GCD 默认提供了：『主队列（Main Dispatch Queue）』。
1. 所有放在主队列中的任务，都会放到主线程中执行。
2. 可使用 dispatch_get_main_queue() 方法获得主队列

注意：主队列其实并不特殊。主队列的实质上就是一个普通的串行队列，只是因为默认情况下，当前代码是放在主队列中的，然后主队列中的代码，有都会放到主线程中去执行，所以才造成了主队列特殊的现象。

// 主队列的获取方法
dispatch_queue_t queue = dispatch_get_main_queue();

对于并发队列，GCD 默认提供了 『全局并发队列（Global Dispatch Queue）』。
1.可以使用 dispatch_get_global_queue 方法来获取全局并发队列。需要传入两个参数。第一个参数表示队列优先级，一般用 DISPATCH_QUEUE_PRIORITY_DEFAULT。第二个参数暂时没用，用 0 即可。

// 全局并发队列的获取方法
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

3.2 任务的创建方法

GCD 提供了同步执行任务的创建方法 dispatch_sync 和异步执行任务创建方法 dispatch_async

// 同步执行任务创建方法
dispatch_sync(queue, ^{
    // 这里放同步执行任务代码
});
// 异步执行任务创建方法
dispatch_async(queue, ^{
    // 这里放异步执行任务代码
});

虽然使用 GCD 只需两步，但是既然我们有两种队列（串行队列 / 并发队列），两种任务执行方式（同步执行 / 异步执行），那么我们就有了四种不同的组合方式。这四种不同的组合方式是：

1.同步执行 + 并发队列
2.异步执行 + 并发队列
3.同步执行 + 串行队列
4.异步执行 + 串行队列

实际上，刚才还说了两种默认队列：全局并发队列、主队列。全局并发队列可以作为普通并发队列来使用。但是当前代码默认放在主队列中，所以主队列很有必要专门来研究一下，所以我们就又多了两种组合方式。这样就有六种不同的组合方式了。

5.同步执行 + 主队列
6.异步执行 + 主队列

那么这几种不同组合方式各有什么区别呢？

3.3 任务和队列不同组合方式的区别

我们先来考虑最基本的使用，也就是当前线程为 『主线程』 的环境下，『不同队列』+『不同任务』 简单组合使用的不同区别。暂时不考虑 『队列中嵌套队列』 的这种复杂情况。

区别	并发队列	串行队列	主队列
同步（sync）	没有开启新线程，串行执行任务	没有开启新线程，串行执行任务	死锁卡住不执行
异步（async	有开启新线程，并发执行任务	有开启新线程（1条），串行执行任务	没有开启新线程，串行执行任务

注意：从上边可看出：『主线程』中调用『主队列』+『同步执行』会导致死锁问题。
这是因为主队列中追加的同步任务和主线程本身的任务两者之间相互等待，阻塞了『主队列』，最终造成了主队列所在的线程（主线程）死锁问题。
而如果我们在『其他线程』调用『主队列』+『同步执行』，则不会阻塞『主队列』，自然也不会造成死锁问题。最终的结果是：不会开启新线程，串行执行任务。

3.4 队列嵌套情况下，不同组合方式区别

除了上边提到的『主线程』中调用『主队列』+『同步执行』会导致死锁问题。实际在使用『串行队列』的时候，也可能出现阻塞『串行队列』所在线程的情况发生，从而造成死锁问题。这种情况多见于同一个串行队列的嵌套使用。

比如下面代码这样：在『异步执行』+『串行队列』的任务中，又嵌套了『当前的串行队列』，然后进行『同步执行』。

dispatch_queue_t queue = dispatch_queue_create("test.queue", DISPATCH_QUEUE_SERIAL);
dispatch_async(queue, ^{    // 异步执行 + 串行队列
    dispatch_sync(queue, ^{  // 同步执行 + 当前串行队列
        // 追加任务 1
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"1---%@",[NSThread currentThread]);      // 打印当前线程
    });
});

执行上面的代码会导致串行队列中追加的任务和串行队列中原有的任务两者之间相互等待，阻塞了『串行队列』，最终造成了串行队列所在的线程（子线程）死锁问题。
主队列造成死锁也是基于这个原因，所以，这也进一步说明了主队列其实并不特殊。

关于『队列中嵌套队列』这种复杂情况，这里也简单做一个总结。不过这里只考虑同一个队列的嵌套情况，关于多个队列的相互嵌套情况还请自行研究，或者等我最新的文章发布。

『不同队列』+『不同任务』组合，以及『队列中嵌套队列』使用的区别：

区别	『异步执行+并发队列』嵌套『同一个并发队列』	『同步执行+并发队列』嵌套『同一个并发队列』	『异步执行+串行队列』嵌套『同一个串行队列』	『同步执行+串行队列』嵌套『同一个串行队列』
同步（sync）	没有开启新的线程，串行执行任务	没有开启新线程，串行执行任务	死锁卡住不执行	死锁卡住不执行
异步（async	有开启新线程，并发执行任务	有开启新线程，并发执行任务	有开启新线程（1 条），串行执行任务	有开启新线程（1 条），串行执行任务

3.5 关于不同队列和不同任务的形象理解

因为前一段时间看到了有朋友留言说对 异步执行 和 并发队列 中创建线程能力有所不理解，我觉得这个问题的确很容易造成困惑，所以很值得拿来专门分析一下。

他的问题：
在异步 + 并发中的解释：
（异步执行具备开启新线程的能力。且并发队列可开启多个线程，同时执行多个任务）
以及同步 + 并发中的解释：
（虽然并发队列可以开启多个线程，并且同时执行多个任务。但是因为本身不能创建新线程，只有当前线程这一个线程（同步任务不具备开启新线程的能力）
这个地方看起来有点疑惑，你两个地方分别提到：异步执行开启新线程，并发队列也可以开启新线程，想请教下，你的意思是只有任务才拥有创建新线程的能力，而队列只有开启线程的能力，并不能创建线程？这二者是这样的关联吗？

关于这个问题，我想做一个很形象的类比，来帮助大家对队列、任务以及线程之间关系的理解。

假设现在有 5 个人要穿过一道门禁，这道门禁总共有 10 个入口，管理员可以决定同一时间打开几个入口，可以决定同一时间让一个人单独通过还是多个人一起通过。不过默认情况下，管理员只开启一个入口，且一个通道一次只能通过一个人。
这个故事里，人好比是任务，管理员好比是系统，入口则代表线程。
5 个人表示有 5 个任务，10 个入口代表 10 条线程。
串行队列好比是 5 个人排成一支长队。
并发队列好比是 5 个人排成多支队伍，比如 2 队，或者 3 队。
同步任务好比是管理员只开启了一个入口（当前线程）。
异步任务好比是管理员同时开启了多个入口（当前线程 + 新开的线程）。
『异步执行 + 并发队列』可以理解为：现在管理员开启了多个入口（比如 3 个入口），5 个人排成了多支队伍（比如 3 支队伍），这样这 5 个人就可以 3 个人同时一起穿过门禁了。
『同步执行 + 并发队列』可以理解为：现在管理员只开启了 1 个入口，5 个人排成了多支队伍。虽然这 5 个人排成了多支队伍，但是只开了 1 个入口啊，这 5 个人虽然都想快点过去，但是 1 个入口一次只能过 1 个人，所以大家就只好一个接一个走过去了，表现的结果就是：顺次通过入口。

换成 GCD 里的语言就是说：

『异步执行 + 并发队列』就是：系统开启了多个线程（主线程+其他子线程），任务可以多个同时运行。
『同步执行 + 并发队列』就是：系统只默认开启了一个主线程，没有开启子线程，虽然任务处于并发队列中，但也只能一个接一个执行了。

4. GCD 的基本使用

先来讲讲并发队列的两种执行方式。

4.1 同步执行 + 并发队列

在当前线程中执行任务，不会开启新线程，执行完一个任务，再执行下一个任务。

/**
 * 同步执行 + 并发队列
 * 特点：在当前线程中执行任务，不会开启新线程，执行完一个任务，再执行下一个任务。
 */
- (void)syncConcurrent {
    NSLog(@"currentThread---%@",[NSThread currentThread]);  // 打印当前线程
    NSLog(@"syncConcurrent---begin");
    
    dispatch_queue_t queue = dispatch_queue_create("net.bujige.testQueue", DISPATCH_QUEUE_CONCURRENT);
    
    dispatch_sync(queue, ^{
        // 追加任务 1
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"1---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    dispatch_sync(queue, ^{
        // 追加任务 2
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"2---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    dispatch_sync(queue, ^{
        // 追加任务 3
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"3---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    NSLog(@"syncConcurrent---end");
}

从 同步执行 + 并发队列 中可看到：

所有任务都是在当前线程（主线程）中执行的，没有开启新的线程（同步执行不具备开启新线程的能力）。
所有任务都在打印的 syncConcurrent---begin 和 syncConcurrent---end 之间执行的（同步任务需要等待队列的任务执行结束）。
任务按顺序执行的。按顺序执行的原因：虽然并发队列可以开启多个线程，并且同时执行多个任务。但是因为本身不能创建新线程，只有当前线程这一个线程（同步任务不具备开启新线程的能力），所以也就不存在并发。而且当前线程只有等待当前队列中正在执行的任务执行完毕之后，才能继续接着执行下面的操作（同步任务需要等待队列的任务执行结束）。所以任务只能一个接一个按顺序执行，不能同时被执行。

4.2 异步执行 + 并发队列

可以开启多个线程，任务交替（同时）执行。

/**
 * 异步执行 + 并发队列
 * 特点：可以开启多个线程，任务交替（同时）执行。
 */
- (void)asyncConcurrent {
    NSLog(@"currentThread---%@",[NSThread currentThread]);  // 打印当前线程
    NSLog(@"asyncConcurrent---begin");
    
    dispatch_queue_t queue = dispatch_queue_create("net.bujige.testQueue", DISPATCH_QUEUE_CONCURRENT);
    
    dispatch_async(queue, ^{
        // 追加任务 1
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"1---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    dispatch_async(queue, ^{
        // 追加任务 2
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"2---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    dispatch_async(queue, ^{
        // 追加任务 3
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"3---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    NSLog(@"asyncConcurrent---end");
}

在异步执行 + 并发队列中可以看出：

除了当前线程（主线程），系统又开启了 3 个线程，并且任务是交替/同时执行的。（异步执行具备开启新线程的能力。且并发队列可开启多个线程，同时执行多个任务）。
所有任务是在打印的 syncConcurrent---begin 和 syncConcurrent---end 之后才执行的。说明当前线程没有等待，而是直接开启了新线程，在新线程中执行任务（异步执行不做等待，可以继续执行任务）。

4.3 同步执行 + 串行队列

不会开启新线程，在当前线程执行任务。任务是串行的，执行完一个任务，再执行下一个任务。

/**
 * 同步执行 + 串行队列
 * 特点：不会开启新线程，在当前线程执行任务。任务是串行的，执行完一个任务，再执行下一个任务。
 */
- (void)syncSerial {
    NSLog(@"currentThread---%@",[NSThread currentThread]);  // 打印当前线程
    NSLog(@"syncSerial---begin");
    
    dispatch_queue_t queue = dispatch_queue_create("net.bujige.testQueue", DISPATCH_QUEUE_SERIAL);
    
    dispatch_sync(queue, ^{
        // 追加任务 1
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"1---%@",[NSThread currentThread]);      // 打印当前线程
    });
    dispatch_sync(queue, ^{
        // 追加任务 2
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"2---%@",[NSThread currentThread]);      // 打印当前线程
    });
    dispatch_sync(queue, ^{
        // 追加任务 3
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"3---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    NSLog(@"syncSerial---end");
}

在 同步执行 + 串行队列 可以看到：

所有任务都是在当前线程（主线程）中执行的，并没有开启新的线程（同步执行不具备开启新线程的能力）。
所有任务都在打印的 syncConcurrent---begin 和 syncConcurrent---end 之间执行（同步任务需要等待队列的任务执行结束）。
任务是按顺序执行的（串行队列每次只有一个任务被执行，任务一个接一个按顺序执行）

4.4 异步执行 + 串行队列

会开启新线程，但是因为任务是串行的，执行完一个任务，再执行下一个任务
串行队列 + 异步 == 只会开启一个线程，且队列中所有的任务都是在这个线程执行

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
    
    dispatch_queue_t queue = dispatch_queue_create("serial", DISPATCH_QUEUE_SERIAL);
    dispatch_async(queue, ^{
        NSLog(@"111:%@",[NSThread currentThread]);
    });
    dispatch_async(queue, ^{
        NSLog(@"222:%@",[NSThread currentThread]);
    });
    dispatch_async(queue, ^{
        NSLog(@"333:%@",[NSThread currentThread]);
    });
}

/**
 * 异步执行 + 串行队列
 * 特点：会开启新线程，但是因为任务是串行的，执行完一个任务，再执行下一个任务。
 */
- (void)asyncSerial {
    NSLog(@"currentThread---%@",[NSThread currentThread]);  // 打印当前线程
    NSLog(@"asyncSerial---begin");
    
    dispatch_queue_t queue = dispatch_queue_create("net.bujige.testQueue", DISPATCH_QUEUE_SERIAL);
    
    dispatch_async(queue, ^{
        // 追加任务 1
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"1---%@",[NSThread currentThread]);      // 打印当前线程
    });
    dispatch_async(queue, ^{
        // 追加任务 2
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"2---%@",[NSThread currentThread]);      // 打印当前线程
    });
    dispatch_async(queue, ^{
        // 追加任务 3
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"3---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    NSLog(@"asyncSerial---end");
}

在 异步执行 + 串行队列 可以看到：

开启了一条新线程（异步执行具备开启新线程的能力，串行队列只开启一个线程）。
所有任务是在打印的 syncConcurrent---begin 和 syncConcurrent---end 之后才开始执行的（异步执行不会做任何等待，可以继续执行任务）。
任务是按顺序执行的（串行队列每次只有一个任务被执行，任务一个接一个按顺序执行）。
下边讲讲刚才我们提到过的：主队列。
主队列：GCD 默认提供的 串行队列。
1.默认情况下，平常所写代码是直接放在主队列中的。
2.所有放在主队列中的任务，都会放到主线程中执行。
3.可使用 dispatch_get_main_queue() 获得主队列。

我们再来看看主队列的两种组合方式

4.5 同步执行 + 主队列

同步执行 + 主队列 在不同线程中调用结果也是不一样，在主线程中调用会发生死锁问题，而在其他线程中调用则不会。

4.5.1 在主线程中调用『同步执行 + 主队列』

互相等待卡住不可行

/**
 * 同步执行 + 主队列
 * 特点(主线程调用)：互等卡主不执行。
 * 特点(其他线程调用)：不会开启新线程，执行完一个任务，再执行下一个任务。
 */
- (void)syncMain {
    
    NSLog(@"currentThread---%@",[NSThread currentThread]);  // 打印当前线程
    NSLog(@"syncMain---begin");
    
    dispatch_queue_t queue = dispatch_get_main_queue();
    
    dispatch_sync(queue, ^{
        // 追加任务 1
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"1---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    dispatch_sync(queue, ^{
        // 追加任务 2
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"2---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    dispatch_sync(queue, ^{
        // 追加任务 3
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"3---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    NSLog(@"syncMain---end");
}

在主线程中使用 同步执行 + 主队列 可以惊奇的发现：

追加到主线程的任务 1、任务 2、任务 3 都不再执行了，而且 syncMain---end 也没有打印，在 XCode 9 及以上版本上还会直接报崩溃。这是为什么呢？

这是因为我们在主线程中执行 syncMain 方法，相当于把 syncMain 任务放到了主线程的队列中。而同步执行会等待当前队列中的任务执行完毕，才会接着执行。那么当我们把任务 1 追加到主队列中，任务 1 就在等待主线程处理完 syncMain任务。而syncMain 任务需要等待任务 1 执行完毕，才能接着执行。
那么，现在的情况就是 syncMain任务和任务 1 都在等对方执行完毕。这样大家互相等待，所以就卡住了，所以我们的任务执行不了，而且 syncMain---end 也没有打印。

要是如果不在主线程中调用，而在其他线程中调用会如何呢？

4.5.2 在其他线程中调用『同步执行 + 主队列』

在其他线程中使用 同步执行 + 主队列 可看到：

所有任务都是在主线程（非当前线程）中执行的，没有开启新的线程（所有放在主队列中的任务，都会放到主线程中执行）。
所有任务都在打印的 syncConcurrent---begin 和 syncConcurrent---end 之间执行（同步任务需要等待队列的任务执行结束）。
任务是按顺序执行的（主队列是 串行队列，每次只有一个任务被执行，任务一个接一个按顺序执行）
为什么现在就不会卡住了呢？
因为syncMain 任务放到了其他线程里，而 任务 1、任务 2、任务3 都在追加到主队列中，这三个任务都会在主线程中执行。syncMain 任务在其他线程中执行到追加任务 1 到主队列中，因为主队列现在没有正在执行的任务，所以，会直接执行主队列的 任务1，等 任务1执行完毕，再接着执行 任务 2、任务 3。所以这里不会卡住线程，也就不会造成死锁问题。

4.6 异步执行 + 主队列

只在主线程中执行任务，执行完一个任务，再执行下一个任务。

/**
 * 异步执行 + 主队列
 * 特点：只在主线程中执行任务，执行完一个任务，再执行下一个任务
 */
- (void)asyncMain {
    NSLog(@"currentThread---%@",[NSThread currentThread]);  // 打印当前线程
    NSLog(@"asyncMain---begin");
    
    dispatch_queue_t queue = dispatch_get_main_queue();
    
    dispatch_async(queue, ^{
        // 追加任务 1
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"1---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    dispatch_async(queue, ^{
        // 追加任务 2
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"2---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    dispatch_async(queue, ^{
        // 追加任务 3
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"3---%@",[NSThread currentThread]);      // 打印当前线程
    });
    
    NSLog(@"asyncMain---end");
}

在 异步执行 + 主队列 可以看到：

所有任务都是在当前线程（主线程）中执行的，并没有开启新的线程（虽然 异步执行 具备开启线程的能力，但因为是主队列，所以所有任务都在主线程中）
所有任务是在打印的 syncConcurrent---begin 和 syncConcurrent---end 之后才开始执行的（异步执行不会做任何等待，可以继续执行任务）。
任务是按顺序执行的（因为主队列是 串行队列，每次只有一个任务被执行，任务一个接一个按顺序执行）。

5. GCD 线程间的通信

在 iOS 开发过程中，我们一般在主线程里边进行 UI 刷新，例如：点击、滚动、拖拽等事件。我们通常把一些耗时的操作放在其他线程，比如说图片下载、文件上传等耗时操作。而当我们有时候在其他线程完成了耗时操作时，需要回到主线程，那么就用到了线程之间的通讯。

/**
 * 线程间通信
 */
- (void)communication {
    // 获取全局并发队列
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    // 获取主队列
    dispatch_queue_t mainQueue = dispatch_get_main_queue();
    
    dispatch_async(queue, ^{
        // 异步追加任务 1
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"1---%@",[NSThread currentThread]);      // 打印当前线程
        
        // 回到主线程
        dispatch_async(mainQueue, ^{
            // 追加在主线程中执行的任务
            [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
            NSLog(@"2---%@",[NSThread currentThread]);      // 打印当前线程
        });
    });
}

可以看到在其他线程中先执行任务，执行完了之后回到主线程执行主线程的相应操作。

6.6 GCD 信号量：dispatch_semaphore

GCD 中的信号量是指Dispatch Semaphore，是持有计数的信号。类似于过高速路收费站的栏杆。可以通过时，打开栏杆，不可以通过时，关闭栏杆。在 Dispatch Semaphore 中，使用计数来完成这个功能，计数小于 0 时等待，不可通过。计数为 0 或大于 0 时，计数减 1 且不等待，可通过。
Dispatch Semaphore 提供了三个方法：

dispatch_semaphore_create：创建一个 Semaphore 并初始化信号的总量
dispatch_semaphore_signal：发送一个信号，让信号总量加 1
dispatch_semaphore_wait：可以使总信号量减 1，信号总量小于 0 时就会一直等待（阻塞所在线程），否则就可以正常执行。

注意：信号量的使用前提是：想清楚你需要处理哪个线程等待（阻塞），又要哪个线程继续执行，然后使用信号量。

Dispatch Semaphore 在实际开发中主要用于：

保持线程同步，将异步执行任务转换为同步执行任务
保证线程安全，为线程加锁

6.6.1 Dispatch Semaphore 线程同步

下面，我们来利用 Dispatch Semaphore 实现线程同步，将异步执行任务转换为同步执行任务。

/**
 * semaphore 线程同步
 */
- (void)semaphoreSync {
    
    NSLog(@"currentThread---%@",[NSThread currentThread]);  // 打印当前线程
    NSLog(@"semaphore---begin");
    
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
    
    __block int number = 0;
    dispatch_async(queue, ^{
        // 追加任务 1
        [NSThread sleepForTimeInterval:2];              // 模拟耗时操作
        NSLog(@"1---%@",[NSThread currentThread]);      // 打印当前线程
        
        number = 100;
        
        dispatch_semaphore_signal(semaphore);
    });
    
    dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
    NSLog(@"semaphore---end,number = %zd",number);
}

从 Dispatch Semaphore 实现线程同步的代码可以看到：

semaphore---end 是在执行完 number = 100; 之后才打印的。而且输出结果 number 为 100。这是因为异步执行不会做任何等待，可以继续执行任务。执行顺如下：
1.semaphore 初始创建时计数为 0。
2.异步执行将任务 1 追加到队列之后，不做等待，接着执行
dispatch_semaphore_wait 方法， semaphore减 1，此时 semaphore == -1，当前线程进入等待状态。
3.然后，异步任务 1 开始执行。任务 1 执行到 dispatch_semaphore_signal 之后，总信号量加 1，此时 semaphore == 0，正在被阻塞的线程（主线程）恢复继续执行。
4.最后打印 semaphore---end, number = 100。

6.6.2 Dispatch Semaphore 线程安全和线程同步（为线程加锁）

线程安全：如果你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。

若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时执行写操作（更改变量），一般都需要考虑线程同步，否则的话就可能影响线程安全。

线程同步：可理解为线程 A 和线程 B 一块配合，A 执行到一定程度时要依靠线程 B 的某个结果，于是停下来，示意 B 运行；B 依言执行，再将结果给 A；A 再继续操作

举个简单例子就是：两个人在一起聊天。两个人不能同时说话，避免听不清(操作冲突)。等一个人说完(一个线程结束操作)，另一个再说(另一个线程再开始操作)。
下面，我们模拟火车票售卖的方式，实现 NSThread 线程安全和解决线程同步问题。

场景：总共有 50 张火车票，有两个售卖火车票的窗口，一个是北京火车票售卖窗口，另一个是上海火车票售卖窗口。两个窗口同时售卖火车票，卖完为止。

6.6.2.2 线程安全（使用 semaphore 加锁）

/**
 * 线程安全：使用 semaphore 加锁
 * 初始化火车票数量、卖票窗口（线程安全）、并开始卖票
 */
- (void)initTicketStatusSave {
    NSLog(@"currentThread---%@",[NSThread currentThread]);  // 打印当前线程
    NSLog(@"semaphore---begin");
    
    semaphoreLock = dispatch_semaphore_create(1);
    
    self.ticketSurplusCount = 50;
    
    // queue1 代表北京火车票售卖窗口
    dispatch_queue_t queue1 = dispatch_queue_create("net.bujige.testQueue1", DISPATCH_QUEUE_SERIAL);
    // queue2 代表上海火车票售卖窗口
    dispatch_queue_t queue2 = dispatch_queue_create("net.bujige.testQueue2", DISPATCH_QUEUE_SERIAL);
    
    __weak typeof(self) weakSelf = self;
    dispatch_async(queue1, ^{
        [weakSelf saleTicketSafe];
    });
    
    dispatch_async(queue2, ^{
        [weakSelf saleTicketSafe];
    });
}

/**
 * 售卖火车票（线程安全）
 */
- (void)saleTicketSafe {
    while (1) {
        // 相当于加锁
        dispatch_semaphore_wait(semaphoreLock, DISPATCH_TIME_FOREVER);
        
        if (self.ticketSurplusCount > 0) {  // 如果还有票，继续售卖
            self.ticketSurplusCount--;
            NSLog(@"%@", [NSString stringWithFormat:@"剩余票数：%d 窗口：%@", self.ticketSurplusCount, [NSThread currentThread]]);
            [NSThread sleepForTimeInterval:0.2];
        } else { // 如果已卖完，关闭售票窗口
            NSLog(@"所有火车票均已售完");
            
            // 相当于解锁
            dispatch_semaphore_signal(semaphoreLock);
            break;
        }
        
        // 相当于解锁
        dispatch_semaphore_signal(semaphoreLock);
    }
}

可以看出，在考虑了线程安全的情况下，使用 dispatch_semaphore 机制之后，得到的票数是正确的，没有出现混乱的情况。我们也就解决了多个线程同步的问题。

7.0 GCD之dispatch_group

之前已经介绍了dispatch_semaphore的底层实现，dispatch_group的实现是基于前者的
假设有这么场景：有一个A耗时操作，B和C两个网络请求当ABC都执行完成后，刷新页面。我们可以用dispatch_group实现。关键如下：

- (void)viewDidLoad {
    [super viewDidLoad];
    
        __block NSInteger number = 0;
    
    dispatch_group_t group = dispatch_group_create();
    
    //A耗时操作
    dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(3);
        number += 2222;
    });
    
    //B网络请求
    dispatch_group_enter(group);
    [self sendRequestWithCompletion:^(id response) {
        number += [response integerValue];
        dispatch_group_leave(group);
    }];
    
    //C网络请求
    dispatch_group_enter(group);
    [self sendRequestWithCompletion:^(id response) {
        number += [response integerValue];
        dispatch_group_leave(group);
    }];
    
    dispatch_group_notify(group, dispatch_get_main_queue(), ^{
        NSLog(@"%zd", number);
    });
}

- (void)sendRequestWithCompletion:(void (^)(id response))completion {
    //模拟一个网络请求
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    dispatch_async(queue, ^{
        sleep(2);
        dispatch_async(dispatch_get_main_queue(), ^{
            if (completion) completion(@1111);
        });
    });
}

接下来我们根据上面的流程来看一下dispatch_group的相关API

dispatch_group_create

dispatch_group_t
dispatch_group_create(void)
{
    return (dispatch_group_t)dispatch_semaphore_create(LONG_MAX);
}

dispatch_group_create其实就是创建了一个value为LONG_MAX的dispatch_semaphore信号量

dispatch_group_async

void
dispatch_group_async(dispatch_group_t dg, dispatch_queue_t dq,
        dispatch_block_t db)
{
    dispatch_group_async_f(dg, dq, _dispatch_Block_copy(db),
            _dispatch_call_block_and_release);
}

dispatch_group_async只是dispatch_group_async_f的封装

dispatch_group_async_f

void
dispatch_group_async_f(dispatch_group_t dg, dispatch_queue_t dq, void *ctxt,
        dispatch_function_t func)
{
    dispatch_continuation_t dc;

    _dispatch_retain(dg);
    dispatch_group_enter(dg);

    dc = fastpath(_dispatch_continuation_alloc_cacheonly());
    if (!dc) {
        dc = _dispatch_continuation_alloc_from_heap();
    }

    dc->do_vtable = (void *)(DISPATCH_OBJ_ASYNC_BIT | DISPATCH_OBJ_GROUP_BIT);
    dc->dc_func = func;
    dc->dc_ctxt = ctxt;
    dc->dc_group = dg;

    // No fastpath/slowpath hint because we simply don't know
    if (dq->dq_width != 1 && dq->do_targetq) {
        return _dispatch_async_f2(dq, dc);
    }

    _dispatch_queue_push(dq, dc);
}

从上面的代码我们可以看出dispatch_group_async_f和dispatch_async_f相似。dispatch_group_async_f多了dispatch_group_enter(dg);，另外在do_vtable的赋值中dispatch_group_async_f多了一个DISPATCH_OBJ_GROUP_BIT的标记符。既然添加了dispatch_group_enter必定会存在dispatch_group_leave。在之前《深入理解GCD之dispatch_queue》介绍_dispatch_continuation_pop函数的源码中有一段代码如下：

    _dispatch_client_callout(dc->dc_ctxt, dc->dc_func);
    if (dg) {
        //group需要进行调用dispatch_group_leave并释放信号
        dispatch_group_leave(dg);
        _dispatch_release(dg);
    }

所以dispatch_group_async_f函数中的dispatch_group_leave是在_dispatch_continuation_pop函数中调用的。
这里概括一下dispatch_group_async_f的工作流程：

调用dispatch_group_enter；
将block和queue等信息记录到dispatch_continuation_t结构体中，并将它加入到group的链表中；
_dispatch_continuation_pop执行时会判断任务是否为group，是的话执行完任务再调用dispatch_group_leave以达到信号量的平衡。

dispatch_group_enter

void
dispatch_group_enter(dispatch_group_t dg)
{
    dispatch_semaphore_t dsema = (dispatch_semaphore_t)dg;

    (void)dispatch_semaphore_wait(dsema, DISPATCH_TIME_FOREVER);
}

dispatch_group_enter将dispatch_group_t转换成dispatch_semaphore_t，并调用dispatch_semaphore_wait，原子性减1后，进入等待状态直到有信号唤醒。所以说
dispatch_group_enter就是对dispatch_semaphore_wait的封装。

dispatch_group_leave

void
dispatch_group_leave(dispatch_group_t dg)
{
    dispatch_semaphore_t dsema = (dispatch_semaphore_t)dg;
    dispatch_atomic_release_barrier();
    long value = dispatch_atomic_inc2o(dsema, dsema_value);//dsema_value原子性加1
    if (slowpath(value == LONG_MIN)) {//内存溢出，由于dispatch_group_leave在dispatch_group_enter之前调用
        DISPATCH_CLIENT_CRASH("Unbalanced call to dispatch_group_leave()");
    }
    if (slowpath(value == dsema->dsema_orig)) {//表示所有任务已经完成，唤醒group
        (void)_dispatch_group_wake(dsema);
    }
}

从上面的源代码中我们看到dispatch_group_leave将dispatch_group_t转换成dispatch_semaphore_t后将dsema_value的值原子性加1。如果value为LONG_MIN程序crash；如果value等于dsema_orig表示所有任务已完成，调用_dispatch_group_wake唤醒group（_dispatch_group_wake的用于和notify有关，我们会在后面介绍）。因为在enter的时候进行了原子性减1操作。所以在leave的时候需要原子性加1。

这里先说明一下enter和leave之间的关系：

dispatch_group_leave与dispatch_group_enter配对使用。当调用了dispatch_group_enter而没有调用dispatch_group_leave时，由于value不等于dsema_orig不会走到唤醒逻辑，dispatch_group_notify中的任务无法执行或者dispatch_group_wait收不到信号而卡住线程。
dispatch_group_enter必须在dispatch_group_leave之前出现。当dispatch_group_leave比dispatch_group_enter多调用了一次或者说在dispatch_group_enter之前被调用的时候，dispatch_group_leave进行原子性加1操作，相当于value为LONGMAX+1，发生数据长度溢出，变成LONG_MIN，由于value == LONG_MIN成立，程序发生crash。

dispatch_group_notify

void
dispatch_group_notify(dispatch_group_t dg, dispatch_queue_t dq,
        dispatch_block_t db)
{
    dispatch_group_notify_f(dg, dq, _dispatch_Block_copy(db),
            _dispatch_call_block_and_release);
}

dispatch_group_notify是dispatch_group_notify_f的封装，具体实现在后者。

dispatch_group_notify_f

void
dispatch_group_notify_f(dispatch_group_t dg, dispatch_queue_t dq, void *ctxt,
        void (*func)(void *))
{
    dispatch_semaphore_t dsema = (dispatch_semaphore_t)dg;
    struct dispatch_sema_notify_s *dsn, *prev;

    //封装dispatch_continuation_t结构体
    // FIXME -- this should be updated to use the continuation cache
    while (!(dsn = calloc(1, sizeof(*dsn)))) {
        sleep(1);
    }

    dsn->dsn_queue = dq;
    dsn->dsn_ctxt = ctxt;
    dsn->dsn_func = func;
    _dispatch_retain(dq);
    dispatch_atomic_store_barrier();
    //将结构体放到链表尾部，如果链表为空同时设置链表头部节点并唤醒group
    prev = dispatch_atomic_xchg2o(dsema, dsema_notify_tail, dsn);
    if (fastpath(prev)) {
        prev->dsn_next = dsn;
    } else {
        _dispatch_retain(dg);
        (void)dispatch_atomic_xchg2o(dsema, dsema_notify_head, dsn);
        if (dsema->dsema_value == dsema->dsema_orig) {//任务已经完成，唤醒group
            _dispatch_group_wake(dsema);
        }
    }
}

所以dispatch_group_notify函数只是用链表把所有回调通知保存起来，等待调用。

_dispatch_group_wake

static long
_dispatch_group_wake(dispatch_semaphore_t dsema)
{
    struct dispatch_sema_notify_s *next, *head, *tail = NULL;
    long rval;
    //将dsema的dsema_notify_head赋值为NULL，同时将之前的内容赋给head
    head = dispatch_atomic_xchg2o(dsema, dsema_notify_head, NULL);
    if (head) {
        // snapshot before anything is notified/woken 
        //将dsema的dsema_notify_tail赋值为NULL，同时将之前的内容赋给tail
        tail = dispatch_atomic_xchg2o(dsema, dsema_notify_tail, NULL);
    }
    //将dsema的dsema_group_waiters设置为0，并返回原来的值
    rval = dispatch_atomic_xchg2o(dsema, dsema_group_waiters, 0);
    if (rval) {
        //循环调用semaphore_signal唤醒当初等待group的信号量，使得dispatch_group_wait函数返回。
        // wake group waiters
#if USE_MACH_SEM
        _dispatch_semaphore_create_port(&dsema->dsema_waiter_port);
        do {
            kern_return_t kr = semaphore_signal(dsema->dsema_waiter_port);
            DISPATCH_SEMAPHORE_VERIFY_KR(kr);
        } while (--rval);
#elif USE_POSIX_SEM
        do {
            int ret = sem_post(&dsema->dsema_sem);
            DISPATCH_SEMAPHORE_VERIFY_RET(ret);
        } while (--rval);
#endif
    }
    if (head) {
        //获取链表，依次调用dispatch_async_f异步执行在notify函数中的任务即Block。
        // async group notify blocks
        do {
            dispatch_async_f(head->dsn_queue, head->dsn_ctxt, head->dsn_func);
            _dispatch_release(head->dsn_queue);
            next = fastpath(head->dsn_next);
            if (!next && head != tail) {
                while (!(next = fastpath(head->dsn_next))) {
                    _dispatch_hardware_pause();
                }
            }
            free(head);
        } while ((head = next));
        _dispatch_release(dsema);
    }
    return 0;
}

_dispatch_group_wake主要的作用有两个：
1.调用semaphore_signal唤醒当初等待group的信号量，使得dispatch_group_wait函数返回。
2.获取链表，依次调用dispatch_async_f异步执行在notify函数中的任务即Block。

到这里我们已经差不多知道了dispatch_group工作过程，我们用一张图表示：

118,GCD的详细理解(同步执行(sync)和异步执行(async)两者的区别是否等待队列的任务执行结束，以及是否具备开启新线程的能力，同步在指定的队列中，添加的任务执行结束之前，会一直等待，..._第6张图片

image.png

dispatch_group_wait

long
dispatch_group_wait(dispatch_group_t dg, dispatch_time_t timeout)
{
    dispatch_semaphore_t dsema = (dispatch_semaphore_t)dg;

    if (dsema->dsema_value == dsema->dsema_orig) {//没有需要执行的任务
        return 0;
    }
    if (timeout == 0) {//返回超时
#if USE_MACH_SEM
        return KERN_OPERATION_TIMED_OUT;
#elif USE_POSIX_SEM
        errno = ETIMEDOUT;
        return (-1);
#endif
    }
    return _dispatch_group_wait_slow(dsema, timeout);
}

dispatch_group_wait用于等待group中的任务完成。

_dispatch_group_wait_slow

static long
_dispatch_group_wait_slow(dispatch_semaphore_t dsema, dispatch_time_t timeout)
{
    long orig;

again:
    // check before we cause another signal to be sent by incrementing
    // dsema->dsema_group_waiters
    if (dsema->dsema_value == dsema->dsema_orig) {
        return _dispatch_group_wake(dsema);
    }
    // Mach semaphores appear to sometimes spuriously wake up. Therefore,
    // we keep a parallel count of the number of times a Mach semaphore is
    // signaled (6880961).
    (void)dispatch_atomic_inc2o(dsema, dsema_group_waiters);
    // check the values again in case we need to wake any threads
    if (dsema->dsema_value == dsema->dsema_orig) {
        return _dispatch_group_wake(dsema);
    }

#if USE_MACH_SEM
    mach_timespec_t _timeout;
    kern_return_t kr;

    _dispatch_semaphore_create_port(&dsema->dsema_waiter_port);

    // From xnu/osfmk/kern/sync_sema.c:
    // wait_semaphore->count = -1; /* we don't keep an actual count */
    //
    // The code above does not match the documentation, and that fact is
    // not surprising. The documented semantics are clumsy to use in any
    // practical way. The above hack effectively tricks the rest of the
    // Mach semaphore logic to behave like the libdispatch algorithm.

    switch (timeout) {
    default:
        do {
            uint64_t nsec = _dispatch_timeout(timeout);
            _timeout.tv_sec = (typeof(_timeout.tv_sec))(nsec / NSEC_PER_SEC);
            _timeout.tv_nsec = (typeof(_timeout.tv_nsec))(nsec % NSEC_PER_SEC);
            kr = slowpath(semaphore_timedwait(dsema->dsema_waiter_port,
                    _timeout));
        } while (kr == KERN_ABORTED);

        if (kr != KERN_OPERATION_TIMED_OUT) {
            DISPATCH_SEMAPHORE_VERIFY_KR(kr);
            break;
        }
        // Fall through and try to undo the earlier change to
        // dsema->dsema_group_waiters
    case DISPATCH_TIME_NOW:
        while ((orig = dsema->dsema_group_waiters)) {
            if (dispatch_atomic_cmpxchg2o(dsema, dsema_group_waiters, orig,
                    orig - 1)) {
                return KERN_OPERATION_TIMED_OUT;
            }
        }
        // Another thread called semaphore_signal().
        // Fall through and drain the wakeup.
    case DISPATCH_TIME_FOREVER:
        do {
            kr = semaphore_wait(dsema->dsema_waiter_port);
        } while (kr == KERN_ABORTED);
        DISPATCH_SEMAPHORE_VERIFY_KR(kr);
        break;
    }
#elif USE_POSIX_SEM
//这部分代码省略
#endif

    goto again;
}

从上面的代码我们发现_dispatch_group_wait_slow和_dispatch_semaphore_wait_slow的逻辑很接近。都利用mach内核的semaphore进行信号的发送。区别在于_dispatch_semaphore_wait_slow在等待结束后是return，而_dispatch_group_wait_slow在等待结束是调用_dispatch_group_wake去唤醒这个group。

dispatch_group 总结：

dispatch_group是一个初始值为LONG_MAX的信号量，group中的任务完成是判断其value是否恢复成初始值。
dispatch_group_enter和dispatch_group_leave必须成对使用并且支持嵌套。
如果dispatch_group_enter比dispatch_group_leave多，由于value不等于dsema_orig不会走到唤醒逻辑，dispatch_group_notify中的任务无法执行或者dispatch_group_wait收不到信号而卡住线程。如果是dispatch_group_leave多，则会引起崩溃。

118,GCD的详细理解(同步执行(sync)和异步执行(async)两者的区别是否等待队列的任务执行结束，以及是否具备开启新线程的能力，同步在指定的队列中，添加的任务执行结束之前，会一直等待，...

1. GCD 任务和队列

同步执行（sync）：

异步执行（async）：

3. GCD 的使用步骤

注意：添加几个任务并不是创建几个线程

3.2 任务的创建方法

那么这几种不同组合方式各有什么区别呢？

3.3 任务和队列不同组合方式的区别

3.4 队列嵌套情况下，不同组合方式区别

3.5 关于不同队列和不同任务的形象理解

4. GCD 的基本使用

先来讲讲并发队列的两种执行方式。

4.1 同步执行 + 并发队列

4.2 异步执行 + 并发队列

4.3 同步执行 + 串行队列

4.4 异步执行 + 串行队列

我们再来看看主队列的两种组合方式

4.5 同步执行 + 主队列

4.5.1 在主线程中调用 『同步执行 + 主队列』

要是如果不在主线程中调用，而在其他线程中调用会如何呢？

4.5.2 在其他线程中调用『同步执行 + 主队列』

4.6 异步执行 + 主队列

5. GCD 线程间的通信

6.6 GCD 信号量：dispatch_semaphore

6.6.1 Dispatch Semaphore 线程同步

6.6.2 Dispatch Semaphore 线程安全和线程同步（为线程加锁）

6.6.2.2 线程安全（使用 semaphore 加锁）

7.0 GCD之dispatch_group

dispatch_group_create

dispatch_group_async

dispatch_group_async_f

dispatch_group_enter

dispatch_group_leave

dispatch_group_notify

dispatch_group_notify_f

_dispatch_group_wake

dispatch_group_wait

_dispatch_group_wait_slow

dispatch_group 总结：

你可能感兴趣的:(118,GCD的详细理解(同步执行(sync)和异步执行(async)两者的区别是否等待队列的任务执行结束，以及是否具备开启新线程的能力，同步在指定的队列中，添加的任务执行结束之前，会一直等待，...)

4.5.1 在主线程中调用『同步执行 + 主队列』