image

Grand Central Dispatch（GCD）是異步執行任務的技術之一。一般將應用程序中記述的線程管理用的代碼在系統級中實現。開發者只需要定義想執行的任務并追加到適當的Dispatch Queue中，GCD就能生成必要的線程并計劃執行任務。由于線程管理是作為系統的一部分來實現的，因此可統一管理，也可執行任務，這樣就比以前的線程更有效率。

本文會以圖文并茂的形式介紹GCD的常用api基礎及線程安全相關，篇幅會比較長。

GCD常用函數

GCD中有2個用來執行任務的函數

同步方式

dispatch_sync(dispatch_queue_t queue, dispatch_block_t block);

異步方式

dispatch_async(dispatch_queue_t queue, dispatch_block_t block);

什么是同步?

在當前線程中執行任務，不具備開啟新線程的能力

什么是異步?

在新的線程中執行任務，具備開啟新線程的能力

什么是并發?

多個任務并發（同時）執行

什么是串行?

一個任務執行完畢后，再執行下一個任務

如下表格所示

下面是本文會講到的內容

GCD的API

• Dispatch Queue

DispatchQueue manages the execution of work items. Each work item submitted to a queue is processed on a pool of threads managed by the system.

image

image

image

dispatch_queue_t serialQueue = dispatch_queue_create("com.slim.www", DISPATCH_QUEUE_SERIAL);
dispatch_async(serialQueue, ^{
NSLog(@"1");
});
dispatch_sync(serialQueue, ^{
NSLog(@"2");
});
dispatch_async(serialQueue, ^{
NSLog(@"3");
});

因為不用等待執行中的處理結束，所以會依次向下打印。結果為1、2、3
為了再次證實串行隊列中只有一個線程執行任務，我們再來看一段代碼

dispatch_queue_t serialQueue = dispatch_queue_create("com.slim.www", DISPATCH_QUEUE_SERIAL);
for (int i = 0; i< 10;i++){
dispatch_async(serialQueue, ^{
NSLog(@"%@--%d",[NSThread currentThread], i);
});
}

打印結果為：

2018-08-23 17:32:17.490879+0800 gcdTest[1447:249018] <NSThread: 0x6000004605c0>{number = 3, name = (null)}--0
2018-08-23 17:32:17.491318+0800 gcdTest[1447:249018] <NSThread: 0x6000004605c0>{number = 3, name = (null)}--1
2018-08-23 17:32:17.492612+0800 gcdTest[1447:249018] <NSThread: 0x6000004605c0>{number = 3, name = (null)}--2
2018-08-23 17:32:17.492777+0800 gcdTest[1447:249018] <NSThread: 0x6000004605c0>{number = 3, name = (null)}--3
.....

我們可以發現thread的地址是一樣的，那就證實了serial queue只有一個線程執行任務

關于Serial Dispatch Queue生成個數的注意事項

• 當生成多個Serial Dispatch Queue時，各個Serial Dispatch Queue將并行執行。
• 如果生成多個Serial Dispatch Queue，那么就會消耗大量內存，引起大量的上下文切換，從而影響性能。
  如下圖所示：

image

image

dispatch_queue_t concurrentQueue = dispatch_queue_create("com.slim.www", DISPATCH_QUEUE_CONCURRENT);
dispatch_async(concurrentQueue, ^{
NSLog(@"1");
});
dispatch_sync(concurrentQueue, ^{
NSLog(@"2");
});
dispatch_async(concurrentQueue, ^{
NSLog(@"3");
});

打印結果為：

2018-08-23 17:38:54.330096+0800 gcdTest[1519:258011] 2
2018-08-23 17:38:54.330096+0800 gcdTest[1519:258048] 1
2018-08-23 17:38:54.330441+0800 gcdTest[1519:258048] 3

我們再來證實一下

dispatch_queue_t concurrentQueue = dispatch_queue_create("com.slim.www", DISPATCH_QUEUE_CONCURRENT);
for (int i = 0; i< 10;i++){
dispatch_async(concurrentQueue, ^{
NSLog(@"%@--%d",[NSThread currentThread], i);
});
}

打印結果為：

<NSThread: 0x6040002754c0>{number = 3, name = (null)}--0
2018-08-23 17:44:00.487048+0800 gcdTest[1585:265970] <NSThread: 0x604000275580>{number = 6, name = (null)}--3
2018-08-23 17:44:00.487104+0800 gcdTest[1585:265971] <NSThread: 0x604000275540>{number = 5, name = (null)}--2
2018-08-23 17:44:00.487112+0800 gcdTest[1585:265968] <NSThread: 0x600000461240>{number = 4, name = (null)}--1
....

可以看出并發隊列中是有多個線程執行任務的。

• dispatch_queue_create

• dispatch_queue_create函數可生成Dispatch Queue

dispatch_queue_t queue = dispatch_queue_create("read_queue", DISPATCH_QUEUE_CONCURRENT);

• 第一個參數為queue名稱，第二個參數為類型

• Main Dispatch Queue/Global Dispatch Queue

• Main Dispatch Queue主線程，追加在Main Dispatch Queue的處理在主線程的runloop進行。所以要將界面更新等必須在主線程執行的處理追加在Main Dispatch Queue使用。

image

• Global Dispatch Queue 是所有程序都能使用的Conncurrent Dispatch Queue，有四個優先級，（High）、（Default）、（Low）、（Background）Conncurrent Dispatch Queue的線程不能保證實時性。

• dispatch_after

• 我們經常會遇到在某個時間之后執行某個方法，那我們可以可以用dispatch_after這個函數來實現。

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[self.navigationController popToRootViewControllerAnimated:YES];
});

比如上面2s返回到rootViewController,并不是在指定的2s后執行處理，而只是在指定時間追加到Dispatch Queue。因為Main Dispatch Queue在主線程中執行，所以runloop如果有正在處理執行的處理，那么這個時間會延遲，那么這個方法會在2s + x后執行，如果Dispatch Queue有大量處理追加線程或者主線程處理本身有延遲時，這個時間會更長。

多線程的安全隱患

• 多個線程可能會訪問同一塊資源，比如多個線程訪問同一個對象、同一個變量、同一個文件

• 當多個線程訪問同一塊資源時，很容易引發數據錯亂和數據安全問題
  如圖所示

  
  
  image

image

多線程安全隱患的解決方案

常見的線程同步技術是：加鎖

image

ios中的線程同步方案

• os_unfair_lock

• os_unfair_lock用于取代不安全的OSSpinLock ，從iOS10開始才支持。
• 從底層調用看，等待os_unfair_lock鎖的線程會處于休眠狀態，并非忙等
• 需要導入頭文件#import <os/lock.h>

os_unfair_lock lock = OS_UNFAIR_LOCK_INIT;
os_unfair_lock_trylock(&lock);
os_unfair_lock_lock(&lock);
os_unfair_lock_unlock(&lock);

• pthread_mutex

• mutex叫做”互斥鎖”，等待鎖的線程會處于休眠狀態
• 需要導入頭文件#import <pthread.h>

//初始化鎖的屬性
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);
//初始化鎖
pthread_mutex_t mutex;
pthread_mutex_init(&mutex, &attr);
//嘗試加鎖
pthread_mutex_trylock (&mutex);
//加鎖
pthread_mutex_lock (&mutex); //解鎖
pthread_mutex_unlock(&mutex);
//銷毀相關資源
pthread_mutexattr_destroy(&attr);
pthread_mutex_destroy (&mutex);

pthread_mutex 條件

//初始化鎖
pthread_mutex_t mutex;
//NULL代表默認屬性
pthread_mutex_init(&mutex, NULL);
//初始化條件
pthread_cond_t condition;
pthread_cond_init(&condition, NULL);
//等待條件 （進入休眠，放開mutex鎖，被喚醒后，會再次對mutex加鎖）
pthread_cond_wait(&condition, &mutex);
// 激活一個等待該條件的線程
pthread_cond_signal(&condition);
//激活所有等待該條件的線程
pthread_cond_broadcast(&condition);
//銷毀資源
pthread_mutex_destroy(&mutex);
pthread_cond_destroy(&condition);

• dispatch_semaphore

• semaphore叫做”信號量”
• 信號量的初始值，可以用來控制線程并發訪問的最大數量
• 信號量的初始值為1，代表同時只允許1條線程訪問資源，保證線程同步

//信號量的初始值
int value = 1;
//初始化信號量
dispatch_semaphore_t semaphore = dispatch_semaphore_create(value);
//如果信號量的值<=0，當前線程就會進入休眠等待（直到信號量的值>0）
//如果信號量的值>0，就減1，然后往下執行后面的代碼
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
//讓信號量的值加1
dispatch_semaphore_signal(semaphore);

• dispatch_queue(DISPATCH_QUEUE_SERIAL)

這個在上面已經提到了

• NSLock、NSRecursiveLock

• NSLock是對mutex普通鎖的封裝
• NSRecursiveLock也是對mutex遞歸鎖的封裝，API跟NSLock基本一致

- (void)lock;
- (void)unlock;
- (BOOL)tryLock;
- (BOOL)lockBeforeDate:(NSDate *)limit;
NSLock *lock = [[NSLock alloc]init];

• NSCondition

• NSCondition是對mutex和cond的封裝

- (void)wait;
- (BOOL)waitUntilDate:(NSDate *)limit;
- (void)signal;
- (void)broadcast;

• NSConditionLock

• NSConditionLock是對NSCondition的進一步封裝，可以設置具體的條件值

- (void)lockWhenCondition:(NSInteger)condition;
- (BOOL)tryLock;
- (BOOL)tryLockWhenCondition:(NSInteger)condition;
- (void)unlockWithCondition:(NSInteger)condition;
- (BOOL)lockBeforeDate:(NSDate *)limit;
- (BOOL)lockWhenCondition:(NSInteger)condition beforeDate:(NSDate *)limit;

• @synchronized

• @synchronized是對mutex遞歸鎖的封裝
• @synchronized(obj)內部會生成obj對應的遞歸鎖，然后進行加鎖、解鎖操作

@synchronized(obj){
//任務
}

下面我們來比較一下他們的性能
對他們分別進行了加鎖解鎖1000次操作
這是日志結果：

2018-08-23 20:04:50.368758+0800 gcdTest[2700:390931] @synchronized: 218.018055 ms
2018-08-23 20:04:50.409929+0800 gcdTest[2700:390931] NSLock: 40.930986 ms
2018-08-23 20:04:50.446109+0800 gcdTest[2700:390931] NSLock + IMP: 35.949945 ms
2018-08-23 20:04:50.482748+0800 gcdTest[2700:390931] NSCondition: 36.401987 ms
2018-08-23 20:04:50.591528+0800 gcdTest[2700:390931] NSConditionLock: 108.524919 ms
2018-08-23 20:04:50.650369+0800 gcdTest[2700:390931] NSRecursiveLock: 58.606982 ms
2018-08-23 20:04:50.678437+0800 gcdTest[2700:390931] pthread_mutex: 27.842999 ms
2018-08-23 20:04:50.700001+0800 gcdTest[2700:390931] os_unfair_lock: 21.309972 ms

• 耗時方面：
• os_unfair_lock耗時最少;
• pthread_mutex其次。
• @synchronized和NSConditionLock效率較差。
  如果考慮性能可以使用os_unfair_lock，如果不考慮性能，只是圖個方便的話，那可以使用@synchronized。

如何實現ios讀寫安全方案?

• 同一時間，只能有1個線程進行寫的操作
• 同一時間，允許有多個線程進行讀的操作
• 同一時間，不允許既有寫的操作，又有讀的操作

ios實現的方案有

• pthread_rwlock：讀寫鎖

//初始化鎖
pthread_rwlock_t lock;
pthread_rwlock_init(&lock, NULL);
//讀加鎖
pthread_rwlock_rdlock(&lock);
//寫加鎖
pthread_rwlock_wrlock(&lock);
//解鎖
pthread_rwlock_unlock(&lock);
//銷毀
pthread_rwlock_destroy(&lock);

• dispatch_barrier_async：異步柵欄調用
• 這個函數傳入的并發隊列必須是自己通過dispatch_queue_cretate創建的
• 如果傳入的是一個串行或是一個全局的并發隊列，那這個函數便等同于dispatch_async函數的效果

dispatch_queue_t queue = dispatch_queue_create("read_queue", DISPATCH_QUEUE_CONCURRENT);
//讀
dispatch_async(queue, ^{

});
//寫
dispatch_barrier_sync(queue, ^{

});

為何會產生死鎖？

定義

所謂死鎖，通常指有兩個線程T1和T2都卡住了，并等待對方完成某些操作。T1不能完成是因為它在等待T2完成。但T2也不能完成，因為它在等待T1完成。于是大家都完不成，就導致了死鎖（DeadLock）。

image

產生死鎖的四個必要條件：

• 互斥條件：一個資源每次只能被一個進程使用。
• 請求與保持條件：一個進程因請求資源而阻塞時，對已獲得的資源保持不放。
• 不剝奪條件:進程已獲得的資源，在末使用完之前，不能強行剝奪。
• 循環等待條件:若干進程之間形成一種頭尾相接的循環等待資源關系。

這四個條件是死鎖的必要條件，只要系統發生死鎖，這些條件必然成立，而只要上述條件之一不滿足，就不會發生死鎖。

來看這段代碼：

dispatch_sync(dispatch_get_main_queue(), ^(void){
NSLog(@"這里死鎖了");
});

執行這個dispatch_get_main_queue隊列的是主線程。執行了dispatch_sync函數后，將block添加到了main_queue中，同時調dispatch_syn這個函數的線程被阻塞，等待block執行完成，而執行主線程隊列任務的線程正是主線程，此時他處于阻塞狀態，所以block永遠不會被執行，因此主線程一直處于阻塞狀態。因此這段代碼運行后不是在block中無法返回，而是無法執行到這個block。

小結

在實際開發中，我們遇到的情況會比較多，大家根據實際情況選擇，本文就不一一列舉，歡迎有問題留言討論。

• Follow: https://github.com/sallenhandong
• blog: https://slimsallen.com