引
對(duì)計(jì)算機(jī)了解的都會(huì)知道信號(hào)量的作用，當(dāng)我們多個(gè)線程要訪問(wèn)同一個(gè)資源的時(shí)候，往往會(huì)設(shè)置一個(gè)信號(hào)量，當(dāng)信號(hào)量大于0的時(shí)候，新的線程可以去操作這個(gè)資源，操作時(shí)信號(hào)量-1，操作完后信號(hào)量+1，當(dāng)信號(hào)量等于0的時(shí)候，必須等待，所以通過(guò)控制信號(hào)量，我們可以控制能夠同時(shí)進(jìn)行的并發(fā)數(shù)。
在網(wǎng)絡(luò)請(qǐng)求的開(kāi)發(fā)中，經(jīng)常會(huì)遇到兩種情況，一種是我在一個(gè)界面需要同時(shí)請(qǐng)求多種數(shù)據(jù)，比如列表數(shù)據(jù)、廣告數(shù)據(jù)等，全部請(qǐng)求到后再一起刷新界面。另一種是我的請(qǐng)求必須滿足一定順序，比如必須先請(qǐng)求個(gè)人信息，然后根據(jù)個(gè)人信息請(qǐng)求相關(guān)內(nèi)容。這些要求對(duì)于普通的操作是可以做到并發(fā)控制和依賴操作的，但是對(duì)于網(wǎng)絡(luò)請(qǐng)求這種需要時(shí)間的請(qǐng)求來(lái)說(shuō)，效果往往與預(yù)期的不一樣，這時(shí)候就需要用信號(hào)量來(lái)做一個(gè)控制。
GCD信號(hào)量
信號(hào)量是一個(gè)整數(shù)，在創(chuàng)建的時(shí)候會(huì)有一個(gè)初始值，這個(gè)初始值往往代表我要控制的同時(shí)操作的并發(fā)數(shù)。在操作中，對(duì)信號(hào)量會(huì)有兩種操作：信號(hào)通知與等待。信號(hào)通知時(shí)，信號(hào)量會(huì)+1，等待時(shí)，如果信號(hào)量大于0，則會(huì)將信號(hào)量-1，否則，會(huì)等待直到信號(hào)量大于0。什么時(shí)候會(huì)大于零呢？往往是在之前某個(gè)操作結(jié)束后，我們發(fā)出信號(hào)通知，讓信號(hào)量+1。
說(shuō)完概念，我們來(lái)看看GCD中的三個(gè)信號(hào)量操作：
- dispatch_semaphore_create：創(chuàng)建一個(gè)信號(hào)量（semaphore）
- dispatch_semaphore_signal：信號(hào)通知，即讓信號(hào)量+1
- dispatch_semaphore_wait：等待，直到信號(hào)量大于0時(shí)，即可操作，同時(shí)將信號(hào)量-1
在使用的時(shí)候，往往會(huì)創(chuàng)建一個(gè)信號(hào)量，然后進(jìn)行多個(gè)操作，每次操作都等待信號(hào)量大于0再操作，同時(shí)信號(hào)昂-1，操作完后將信號(hào)量+1，類似下面這個(gè)過(guò)程：
dispatch_semaphore_t sema = dispatch_semaphore_create(5);
for (100次循環(huán)操作） {
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// 操作
dispatch_semaphore_signal(sema);
});
}
上面代碼表示我要操作100次，但是控制允許同時(shí)并發(fā)的操作最多只有5次，當(dāng)并發(fā)量達(dá)到5后，信號(hào)量就減小到0了，這時(shí)候wait操作會(huì)起作用，DISPATCH_TIME_FOREVER表示會(huì)永遠(yuǎn)等待，一直等到信號(hào)量大于0，也就是有操作完成了，將信號(hào)量+1了，這時(shí)候才可以結(jié)束等待，進(jìn)行操作，并且將信號(hào)量-1，這樣新的任務(wù)又要等待。
多個(gè)請(qǐng)求結(jié)束后統(tǒng)一操作
假設(shè)我們一個(gè)頁(yè)面需要同時(shí)進(jìn)行多個(gè)請(qǐng)求，他們之間倒是不要求順序關(guān)系，但是要求等他們都請(qǐng)求完畢了再進(jìn)行界面刷新或者其他什么操作。
這個(gè)需求我們一般可以用GCD的group和notify來(lái)做到：
dispatch_group_t group = dispatch_group_create();
dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//請(qǐng)求1
NSLog(@"Request_1");
});
dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//請(qǐng)求2
NSLog(@"Request_2");
});
dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//請(qǐng)求3
NSLog(@"Request_3");
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
//界面刷新
NSLog(@"任務(wù)均完成，刷新界面");
});
notify的作用就是在group中的其他操作全部完成后，再操作自己的內(nèi)容，所以我們會(huì)看到上面三個(gè)內(nèi)容都打印出來(lái)后，才打印界面刷新的內(nèi)容。
但是當(dāng)將上面三個(gè)操作改成真實(shí)的網(wǎng)絡(luò)操作后，這個(gè)簡(jiǎn)單的做法會(huì)變得無(wú)效，為什么呢？因?yàn)榫W(wǎng)絡(luò)請(qǐng)求需要時(shí)間，而線程的執(zhí)行并不會(huì)等待請(qǐng)求完成后才真正算作完成，而是只負(fù)責(zé)將請(qǐng)求發(fā)出去，線程就認(rèn)為自己的任務(wù)算完成了，當(dāng)三個(gè)請(qǐng)求都發(fā)送出去，就會(huì)執(zhí)行notify中的內(nèi)容，但請(qǐng)求結(jié)果返回的時(shí)間是不一定的，也就導(dǎo)致界面都刷新了，請(qǐng)求才返回，這就是無(wú)效的。
要解決這個(gè)問(wèn)題，我們就要用到上面說(shuō)的信號(hào)量來(lái)操作了。
在每個(gè)請(qǐng)求開(kāi)始之前，我們創(chuàng)建一個(gè)信號(hào)量，初始為0，在請(qǐng)求操作之后，我們?cè)O(shè)一個(gè)dispatch_semaphore_wait，在請(qǐng)求到結(jié)果之后，再將信號(hào)量+1，也即是dispatch_semaphore_signal。這樣做的目的是保證在請(qǐng)求結(jié)果沒(méi)有返回之前，一直讓線程等待在那里，這樣一個(gè)線程的任務(wù)一直在等待，就不會(huì)算作完成，notify的內(nèi)容也就不會(huì)執(zhí)行了，直到每個(gè)請(qǐng)求的結(jié)果都返回了，線程任務(wù)才能夠結(jié)束，這時(shí)候notify也才能夠執(zhí)行。偽代碼如下：
dispatch_semaphore_t sema = dispatch_semaphore_create(0);
[網(wǎng)絡(luò)請(qǐng)求:{
成功：dispatch_semaphore_signal(sema);
失?。篸ispatch_semaphore_signal(sema);
}];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
多個(gè)請(qǐng)求順序執(zhí)行
有時(shí)候我們需要按照順序執(zhí)行多次請(qǐng)求，比如先請(qǐng)求到用戶信息，然后根據(jù)用戶信息中的內(nèi)容去請(qǐng)求相關(guān)的數(shù)據(jù)，這在平常的代碼中直接按照順序往下寫(xiě)代碼就可以了，但這里因?yàn)樯婕暗蕉嗑€程之間的關(guān)系，就叫做線程依賴。
線程依賴用GCD做比較麻煩，建議用NSOperationQueue做，可以更加方便的設(shè)置任務(wù)之間的依賴。
// 1.任務(wù)一：獲取用戶信息
NSBlockOperation *operation1 = [NSBlockOperation blockOperationWithBlock:^{
[self request_A];
}];
// 2.任務(wù)二：請(qǐng)求相關(guān)數(shù)據(jù)
NSBlockOperation *operation2 = [NSBlockOperation blockOperationWithBlock:^{
[self request_B];
}];
// 3.設(shè)置依賴
[operation2 addDependency:operation1];// 任務(wù)二依賴任務(wù)一
// 4.創(chuàng)建隊(duì)列并加入任務(wù)
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
[queue addOperations:@[operation2, operation1] waitUntilFinished:NO];
一般的多線程操作這樣做是可以的，線程2會(huì)等待線程1完成后再執(zhí)行。但是對(duì)于網(wǎng)絡(luò)請(qǐng)求，問(wèn)題又來(lái)了，同樣，網(wǎng)絡(luò)請(qǐng)求需要時(shí)間，線程發(fā)出請(qǐng)求后即認(rèn)為任務(wù)完成了，并不會(huì)等待返回后的操作，這就失去了意義。
要解決這個(gè)問(wèn)題，還是用信號(hào)量來(lái)控制，其實(shí)是一個(gè)道理，代碼也是一樣的，在一個(gè)任務(wù)操作中：
dispatch_semaphore_t sema = dispatch_semaphore_create(0);
[網(wǎng)絡(luò)請(qǐng)求:{
成功：dispatch_semaphore_signal(sema);
失?。篸ispatch_semaphore_signal(sema);
}];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
還是去等待請(qǐng)求返回后，才讓任務(wù)結(jié)束。而依賴關(guān)系則通過(guò)NSOperationQueue來(lái)實(shí)現(xiàn)。
結(jié)
其實(shí)歸根結(jié)底，中心思想就是通過(guò)信號(hào)量，來(lái)控制線程任務(wù)什么時(shí)候算作結(jié)束，如果不用信號(hào)量，請(qǐng)求發(fā)出后即認(rèn)為任務(wù)完成，而網(wǎng)絡(luò)請(qǐng)求又要不同時(shí)間，所以會(huì)打亂順序。因此用一個(gè)信號(hào)量來(lái)控制在單個(gè)線程操作內(nèi)，必須等待請(qǐng)求返回，自己要執(zhí)行的操作完成后，才將信號(hào)量+1，這時(shí)候一直處于等待的代碼也得以執(zhí)行通過(guò)，任務(wù)才算作完成。
通過(guò)這個(gè)方法，就可以解決由于網(wǎng)絡(luò)請(qǐng)求耗時(shí)特性而帶來(lái)的一些意想不到的多線程處理的問(wèn)題。
參考資料：
1、http://www.cocoachina.com/ios/20170428/19150.html
2、http://blog.csdn.net/fhbystudy/article/details/25918451
