文章摘自? http://blog.csdn.net/cloudox_/article/details/71107179
引
對(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è)控制。
信號(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_tgroup= dispatch_group_create();? ? dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{//請(qǐng)求1NSLog(@"Request_1");? ? });? ? dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{//請(qǐng)求2NSLog(@"Request_2");? ? });? ? dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{//請(qǐng)求3NSLog(@"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);
? ? ? ? 失斀汲ⅰ：dispatch_semaphore_signal(sema);
}];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER)
有時(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:^{? ? ? ? [selfrequest_A];? ? }];// 2.任務(wù)二：請(qǐng)求相關(guān)數(shù)據(jù)NSBlockOperation *operation2 = [NSBlockOperation blockOperationWithBlock:^{? ? ? ? [selfrequest_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);
? ? ? ? 失敽选：dispatch_semaphore_signal(sema);
}];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
還是去等待請(qǐng)求返回后，才讓任務(wù)結(jié)束议双。而依賴關(guān)系則通過(guò)NSOperationQueue來(lái)實(shí)現(xiàn)痘番。
其實(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)題损趋。
