1. GCD 任務和隊列

學習 GCD 之前，先來了解 GCD 中兩個核心概念：『任務』 和 『隊列』。
任務：就是執行操作的意思，換句話說就是你在線程中執行的那段代碼。在 GCD 中是放在 block 中的。執行任務有兩種方式：『同步執行』 和 『異步執行』。兩者的主要區別是：是否等待隊列的任務執行結束，以及是否具備開啟新線程的能力。

• 同步執行（sync）：

  1.同步添加任務到指定的隊列中，在添加的任務執行結束之前，會一直等待，直到隊列里面的任務完成之后再繼續執行。
  2.只能在當前線程中執行任務，不具備開啟新線程的能力

• 異步執行（async）：

  1.異步添加任務到指定的隊列中，它不會做任何等待，可以繼續執行任務
  2.可以在新的線程中執行任務，具備開啟新線程的能力

舉個簡單例子：你要打電話給小明和小白。
『同步執行』 就是：你打電話給小明的時候，不能同時打給小白。只有等到給小明打完了，才能打給小白（等待任務執行結束）。而且只能用當前的電話（不具備開啟新線程的能力）。
『異步執行』 就是：你打電話給小明的時候，不用等著和小明通話結束（不用等待任務執行結束），還能同時給小白打電話。而且除了當前電話，你還可以使用其他一個或多個電話（具備開啟新線程的能力）

注意：異步執行（async）雖然具有開啟新線程的能力，但是并不一定開啟新線程。這跟任務所指定的隊列類型有關（下面會講）。

隊列（Dispatch Queue）：這里的隊列指執行任務的等待隊列，即用來存放任務的隊列。隊列是一種特殊的線性表，采用 FIFO（先進先出）的原則，即新任務總是被插入到隊列的末尾，而讀取任務的時候總是從隊列的頭部開始讀取。每讀取一個任務，則從隊列中釋放一個任務。隊列的結構可參考下圖：

image.png

• 串行隊列（Serial Dispatch Queue）：
  每次只有一個任務被執行。讓任務一個接著一個地執行。（只開啟一個線程，一個任務執行完畢后，再執行下一個任務）
• 并發隊列（Concurrent Dispatch Queue）:
  可以讓多個任務并發（同時）執行。（可以開啟多個線程，并且同時執行任務）

注意：并發隊列 的并發功能只有在異步（dispatch_async）方法下才有效。

兩者具體區別如下兩圖所示：

image.png

image.png

3. GCD 的使用步驟

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

這個NULL 表示之前的DISPATCH_QUEUE_SERIAL

注意：添加幾個任務并不是創建幾個線程

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

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

GCD 的使用步驟其實很簡單，只有兩步：

1. 創建一個隊列（串行隊列或并發隊列）；
2. 將任務追加到任務的等待隊列中，然后系統就會根據任務類型執行任務（同步執行或異步執行）。

下邊來看看隊列的創建方法 / 獲取方法，以及任務的創建方法。

• 可以使用 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 任務和隊列不同組合方式的區別

我們先來考慮最基本的使用，也就是當前線程為 『主線程』 的環境下，『不同隊列』+『不同任務』 簡單組合使用的不同區別。暫時不考慮 『隊列中嵌套隊列』 的這種復雜情況。

注意：從上邊可看出： 『主線程』 中調用 『主隊列』+『同步執行』 會導致死鎖問題。
這是因為 主隊列中追加的同步任務 和 主線程本身的任務 兩者之間相互等待，阻塞了 『主隊列』，最終造成了主隊列所在的線程（主線程）死鎖問題。
而如果我們在 『其他線程』 調用 『主隊列』+『同步執行』，則不會阻塞 『主隊列』，自然也不會造成死鎖問題。最終的結果是：不會開啟新線程，串行執行任務。

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]);      // 打印當前線程
    });
});

執行上面的代碼會導致 串行隊列中追加的任務 和 串行隊列中原有的任務 兩者之間相互等待，阻塞了『串行隊列』，最終造成了串行隊列所在的線程（子線程）死鎖問題。
主隊列造成死鎖也是基于這個原因，所以，這也進一步說明了主隊列其實并不特殊。

關于 『隊列中嵌套隊列』這種復雜情況，這里也簡單做一個總結。不過這里只考慮同一個隊列的嵌套情況，關于多個隊列的相互嵌套情況還請自行研究，或者等我最新的文章發布。

『不同隊列』+『不同任務』 組合，以及 『隊列中嵌套隊列』 使用的區別：

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<UITouch *> *)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的工作流程：

1. 調用dispatch_group_enter；
2. 將block和queue等信息記錄到dispatch_continuation_t結構體中，并將它加入到group的鏈表中；
3. _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之間的關系：

1. dispatch_group_leave與dispatch_group_enter配對使用。當調用了dispatch_group_enter而沒有調用dispatch_group_leave時，由于value不等于dsema_orig不會走到喚醒邏輯，dispatch_group_notify中的任務無法執行或者dispatch_group_wait收不到信號而卡住線程。
2. 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 <rdar://problem/8554546>
        //將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工作過程，我們用一張圖表示：

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 總結：

1. dispatch_group是一個初始值為LONG_MAX的信號量，group中的任務完成是判斷其value是否恢復成初始值。
2. dispatch_group_enter和dispatch_group_leave必須成對使用并且支持嵌套。
3. 如果dispatch_group_enter比dispatch_group_leave多，由于value不等于dsema_orig不會走到喚醒邏輯，dispatch_group_notify中的任務無法執行或者dispatch_group_wait收不到信號而卡住線程。如果是dispatch_group_leave多，則會引起崩潰。