引

對計算機瞭解的都會知道訊號量的作用，當我們多個執行緒要訪問同一個資源的時候，往往會設定一個訊號量，當訊號量大於0的時候，新的執行緒可以去操作這個資源，操作時訊號量-1，操作完後訊號量+1，當訊號量等於0的時候，必須等待，所以通過控制訊號量，我們可以控制能夠同時進行的併發數。

在網路請求的開發中，經常會遇到兩種情況，一種是我在一個介面需要同時請求多種資料，比如列表資料、廣告資料等，全部請求到後再一起重新整理介面。另一種是我的請求必須滿足一定順序，比如必須先請求個人資訊，然後根據個人資訊請求相關內容。這些要求對於普通的操作是可以做到併發控制和依賴操作的，但是對於網路請求這種需要時間的請求來說，效果往往與預期的不一樣，這時候就需要用訊號量來做一個控制。

GCD訊號量

訊號量是一個整數，在建立的時候會有一個初始值，這個初始值往往代表我要控制的同時操作的併發數。在操作中，對訊號量會有兩種操作：訊號通知與等待。訊號通知時，訊號量會+1，等待時，如果訊號量大於0，則會將訊號量-1，否則，會等待直到訊號量大於0。什麼時候會大於零呢？往往是在之前某個操作結束後，我們發出訊號通知，讓訊號量+1。

說完概念，我們來看看GCD中的三個訊號量操作：

• dispatch_semaphore_create：建立一個訊號量（semaphore）
• dispatch_semaphore_signal：訊號通知，即讓訊號量+1
• dispatch_semaphore_wait：等待，直到訊號量大於0時，即可操作，同時將訊號量-1

在使用的時候，往往會建立一個訊號量，然後進行多個操作，每次操作都等待訊號量大於0再操作，同時訊號昂-1，操作完後將訊號量+1，類似下面這個過程：

dispatch_semaphore_t sema = dispatch_semaphore_create(5);
for (100次迴圈操作） {
    dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        // 操作
        dispatch_semaphore_signal(sema);
    });
}
 

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

上面程式碼表示我要操作100次，但是控制允許同時併發的操作最多隻有5次，當併發量達到5後，訊號量就減小到0了，這時候wait操作會起作用，DISPATCH_TIME_FOREVER表示會永遠等待，一直等到訊號量大於0，也就是有操作完成了，將訊號量+1了，這時候才可以結束等待，進行操作，並且將訊號量-1，這樣新的任務又要等待。

多個請求結束後統一操作

假設我們一個頁面需要同時進行多個請求，他們之間倒是不要求順序關係，但是要求等他們都請求完畢了再進行介面重新整理或者其他什麼操作。

這個需求我們一般可以用GCD的group和notify來做到：

    dispatch_group_t group = dispatch_group_create();
    dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        //請求1
        NSLog(@"Request_1");
    });
    dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        //請求2
        NSLog(@"Request_2");
    });
    dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        //請求3
        NSLog(@"Request_3");
    });
    dispatch_group_notify(group, dispatch_get_main_queue(), ^{
        //介面重新整理
        NSLog(@"任務均完成，重新整理介面");
    });

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17

notify的作用就是在group中的其他操作全部完成後，再操作自己的內容，所以我們會看到上面三個內容都打印出來後，才打印介面重新整理的內容。

但是當將上面三個操作改成真實的網路操作後，這個簡單的做法會變得無效，為什麼呢？因為網路請求需要時間，而執行緒的執行並不會等待請求完成後才真正算作完成，而是隻負責將請求發出去，執行緒就認為自己的任務算完成了，當三個請求都發送出去，就會執行notify中的內容，但請求結果返回的時間是不一定的，也就導致介面都重新整理了，請求才返回，這就是無效的。

要解決這個問題，我們就要用到上面說的訊號量來操作了。

在每個請求開始之前，我們建立一個訊號量，初始為0，在請求操作之後，我們設一個dispatch_semaphore_wait，在請求到結果之後，再將訊號量+1，也即是dispatch_semaphore_signal。這樣做的目的是保證在請求結果沒有返回之前，一直讓執行緒等待在那裡，這樣一個執行緒的任務一直在等待，就不會算作完成，notify的內容也就不會執行了，直到每個請求的結果都返回了，執行緒任務才能夠結束，這時候notify也才能夠執行。虛擬碼如下：

dispatch_semaphore_t sema = dispatch_semaphore_create(0);
[網路請求:{
        成功：dispatch_semaphore_signal(sema);
        失敗：dispatch_semaphore_signal(sema);
}];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);

• 1
• 2
• 3
• 4
• 5
• 6

多個請求順序執行

有時候我們需要按照順序執行多次請求，比如先請求到使用者資訊，然後根據使用者資訊中的內容去請求相關的資料，這在平常的程式碼中直接按照順序往下寫程式碼就可以了，但這裡因為涉及到多執行緒之間的關係，就叫做執行緒依賴。

執行緒依賴用GCD做比較麻煩，建議用NSOperationQueue做，可以更加方便的設定任務之間的依賴。

    // 1.任務一：獲取使用者資訊
    NSBlockOperation *operation1 = [NSBlockOperation blockOperationWithBlock:^{
        [self request_A];
    }];

    // 2.任務二：請求相關資料
    NSBlockOperation *operation2 = [NSBlockOperation blockOperationWithBlock:^{
        [self request_B];
    }];

    // 3.設定依賴
    [operation2 addDependency:operation1];// 任務二依賴任務一

    // 4.建立佇列並加入任務
    NSOperationQueue *queue = [[NSOperationQueue alloc] init];
    [queue addOperations:@[operation2, operation1] waitUntilFinished:NO];

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16

一般的多執行緒操作這樣做是可以的，執行緒2會等待執行緒1完成後再執行。但是對於網路請求，問題又來了，同樣，網路請求需要時間，執行緒發出請求後即認為任務完成了，並不會等待返回後的操作，這就失去了意義。

要解決這個問題，還是用訊號量來控制，其實是一個道理，程式碼也是一樣的，在一個任務操作中：

dispatch_semaphore_t sema = dispatch_semaphore_create(0);
[網路請求:{
        成功：dispatch_semaphore_signal(sema);
        失敗：dispatch_semaphore_signal(sema);
}];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);

• 1
• 2
• 3
• 4
• 5
• 6

還是去等待請求返回後，才讓任務結束。而依賴關係則通過NSOperationQueue來實現。

結

其實歸根結底，中心思想就是通過訊號量，來控制執行緒任務什麼時候算作結束，如果不用訊號量，請求發出後即認為任務完成，而網路請求又要不同時間，所以會打亂順序。因此用一個訊號量來控制在單個執行緒操作內，必須等待請求返回，自己要執行的操作完成後，才將訊號量+1，這時候一直處於等待的程式碼也得以執行通過，任務才算作完成。

通過這個方法，就可以解決由於網路請求耗時特性而帶來的一些意想不到的多執行緒處理的問題。