IOS 多執行緒知識學習
在這篇文章中,我將為你整理一下 iOS 開發中幾種多執行緒方案,以及其使用方法和注意事項。當然也會給出幾種多執行緒的案例,在實際使用中感受它們的區別。還有一點需要說明的是,這篇文章將會使用 Swift 和 Objective-c 兩種語言講解,雙語幼兒園。OK,let’s begin!
概述
這篇文章中,我不會說多執行緒是什麼、執行緒和程序的區別、多執行緒有什麼用,當然我也不會說什麼是序列、什麼是並行等問題,這些我們應該都知道的。
在 iOS 中其實目前有 4 套多執行緒方案,他們分別是:
Pthreads
NSThread
GCD
NSOperation & NSOperationQueue
所以接下來,我會一一講解這些方案的使用方法和一些案例。在將這些內容的時候,我也會順帶說一些多執行緒周邊產品。比如: 執行緒同步、 延時執行、 單例模式 等等。
Pthreads
其實這個方案不用說的,只是拿來充個數,為了讓大家瞭解一下就好了。百度百科裡是這麼說的:
POSIX執行緒(POSIX threads),簡稱Pthreads,是執行緒的POSIX標準。該標準定義了建立和操縱執行緒的一整套API。在類Unix作業系統(Unix、Linux、Mac OS X等)中,都使用Pthreads作為作業系統的執行緒。
簡單地說,這是一套在很多作業系統上都通用的多執行緒API,所以移植性很強(然並卵),當然在 iOS 中也是可以的。不過這是基於 c語言 的框架,使用起來這酸爽!感受一下:
OBJECTIVE-C
當然第一步要包含標頭檔案
import
define NSEC_PER_SEC 1000000000ull
define USEC_PER_SEC 1000000ull
define NSEC_PER_USEC 1000ull
關鍵詞解釋:
NSEC:納秒。
USEC:微妙。
SEC:秒
PER:每
所以:
NSEC_PER_SEC,每秒有多少納秒。
USEC_PER_SEC,每秒有多少毫秒。(注意是指在納秒的基礎上)
NSEC_PER_USEC,每毫秒有多少納秒。
所以,延時1秒可以寫成如下幾種:
dispatch_time(DISPATCH_TIME_NOW, 1 * NSEC_PER_SEC);
dispatch_time(DISPATCH_TIME_NOW, 1000 * USEC_PER_SEC);
dispatch_time(DISPATCH_TIME_NOW, USEC_PER_SEC * NSEC_PER_USEC);
最後一個“USEC_PER_SEC * NSEC_PER_USEC”,翻譯過來就是“每秒的毫秒數乘以每毫秒的納秒數”,也就是“每秒的納秒數”,所以,延時500毫秒之類的,也就不難了吧~
dispatch_suspend != 立即停止佇列的執行
dispatch_suspend,dispatch_resume提供了“掛起、恢復”佇列的功能,簡單來說,就是可以暫停、恢復佇列上的任務。但是這裡的“掛起”,並不能保證可以立即停止佇列上正在執行的block,看如下例子:
dispatch_queue_t queue = dispatch_queue_create(“me.tutuge.test.gcd”, DISPATCH_QUEUE_SERIAL);
//提交第一個block,延時5秒列印。
dispatch_async(queue, ^{
[NSThread sleepForTimeInterval:5];
NSLog(@”After 5 seconds…”);
});
//提交第二個block,也是延時5秒列印
dispatch_async(queue, ^{
[NSThread sleepForTimeInterval:5];
NSLog(@”After 5 seconds again…”);
});
//延時一秒
NSLog(@”sleep 1 second…”);
[NSThread sleepForTimeInterval:1];
//掛起佇列
NSLog(@”suspend…”);
dispatch_suspend(queue);
//延時10秒
NSLog(@”sleep 10 second…”);
[NSThread sleepForTimeInterval:10];
//恢復佇列
NSLog(@”resume…”);
dispatch_resume(queue);
執行結果如下:
2015-04-01 00:32:09.903 GCDTest[47201:1883834] sleep 1 second…
2015-04-01 00:32:10.910 GCDTest[47201:1883834] suspend…
2015-04-01 00:32:10.910 GCDTest[47201:1883834] sleep 10 second…
2015-04-01 00:32:14.908 GCDTest[47201:1883856] After 5 seconds…
2015-04-01 00:32:20.911 GCDTest[47201:1883834] resume…
2015-04-01 00:32:25.912 GCDTest[47201:1883856] After 5 seconds again…
可知,在dispatch_suspend掛起佇列後,第一個block還是在執行,並且正常輸出。
結合文件,我們可以得知,dispatch_suspend並不會立即暫停正在執行的block,而是在當前block執行完成後,暫停後續的block執行。
所以下次想暫停正在佇列上執行的block時,還是不要用dispatch_suspend了吧~
“同步”的dispatch_apply
dispatch_apply的作用是在一個佇列(序列或並行)上“執行”多次block,其實就是簡化了用迴圈去向佇列依次新增block任務。但是我個人覺得這個函式就是個“坑”,先看看如下程式碼執行結果:
//建立非同步序列佇列
dispatch_queue_t queue = dispatch_queue_create(“me.tutuge.test.gcd”, DISPATCH_QUEUE_SERIAL);
//執行block3次
dispatch_apply(3, queue, ^(size_t i) {
NSLog(@”apply loop: %zu”, i);
});
//列印資訊
NSLog(@”After apply”);
執行的結果是:
2015-04-01 00:55:40.854 GCDTest[47402:1893289] apply loop: 0
2015-04-01 00:55:40.856 GCDTest[47402:1893289] apply loop: 1
2015-04-01 00:55:40.856 GCDTest[47402:1893289] apply loop: 2
2015-04-01 00:55:40.856 GCDTest[47402:1893289] After apply
看,明明是提交到非同步的佇列去執行,但是“After apply”居然在apply後列印,也就是說,dispatch_apply將外面的執行緒(main執行緒)“阻塞”了!
檢視官方文件,dispatch_apply確實會“等待”其所有的迴圈執行完畢才往下執行=。=,看來要小心使用了。
避免死鎖!
dispatch_sync導致的死鎖
涉及到多執行緒的時候,不可避免的就會有“死鎖”這個問題,在使用GCD時,往往一不小心,就可能造成死鎖,看看下面的“死鎖”例子:
//在main執行緒使用“同步”方法提交Block,必定會死鎖。
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@”I am block…”);
});
你可能會說,這麼低階的錯誤,我怎麼會犯,那麼,看看下面的:
(void)updateUI1 {
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@”Update ui 1”);//死鎖! [self updateUI2];
});
}(void)updateUI2 {
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@”Update ui 2”);
});
}
在你不注意的時候,巢狀呼叫可能就會造成死鎖!所以為了“世界和平”=。=,我們還是少用dispatch_sync吧。
dispatch_apply導致的死鎖!
啥,dispatch_apply導致的死鎖?。。。是的,前一節講到,dispatch_apply會等迴圈執行完成,這不就差不多是阻塞了嗎。看如下例子:
dispatch_queue_t queue = dispatch_queue_create(“me.tutuge.test.gcd”, DISPATCH_QUEUE_SERIAL);
dispatch_apply(3, queue, ^(size_t i) {
NSLog(@”apply loop: %zu”, i);
//再來一個dispatch_apply!死鎖!
dispatch_apply(3, queue, ^(size_t j) {
NSLog(@"apply loop inside %zu", j);
});
});
這端程式碼只會輸出“apply loop: 1”。。。就沒有然後了=。=
所以,一定要避免dispatch_apply的巢狀呼叫。
靈活使用dispatch_group
很多時候我們需要等待一系列任務(block)執行完成,然後再做一些收尾的工作。如果是有序的任務,可以分步驟完成的,直接使用序列佇列就行。但是如果是一系列並行執行的任務呢?這個時候,就需要dispatch_group幫忙了~總的來說,dispatch_group的使用分如下幾步:
建立dispatch_group_t
新增任務(block)
新增結束任務(如清理操作、通知UI等)
下面著重講講在後面兩步。
新增任務
新增任務可以分為以下兩種情況:
自己建立佇列:使用dispatch_group_async。
無法直接使用佇列變數(如使用AFNetworking新增非同步任務):使用dispatch_group_enter,dispatch_group_leave。
自己建立佇列時,當然就用dispatch_group_async函式,簡單有效,簡單例子如下:
//省去建立group、queue程式碼。。。
dispatch_group_async(group, queue, ^{
//Do you work…
});
當你無法直接使用佇列變數時,就無法使用dispatch_group_async了,下面以使用AFNetworking時的情況:
AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
//Enter group
dispatch_group_enter(group);
[manager GET:@”http://www.baidu.com” parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {
//Deal with result…
//Leave group
dispatch_group_leave(group);
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
//Deal with error…
//Leave group
dispatch_group_leave(group);
}];
//More request…
使用dispatch_group_enter,dispatch_group_leave就可以方便的將一系列網路請求“打包”起來~
新增結束任務
新增結束任務也可以分為兩種情況,如下:
在當前執行緒阻塞的同步等待:dispatch_group_wait。
新增一個非同步執行的任務作為結束任務:dispatch_group_notify
這兩個比較簡單,就不再貼程式碼了=。=
使用dispatch_barrier_async,dispatch_barrier_sync的注意事項
dispatch_barrier_async的作用就是向某個佇列插入一個block,當目前正在執行的block執行完成後,阻塞這個block後面新增的block,只執行這個block直到完成,然後再繼續後續的任務,有點“唯我獨尊”的感覺=。=
值得注意的是:
dispatchbarrier(a)sync只在自己建立的併發佇列上有效,在全域性(Global)併發佇列、序列佇列上,效果跟dispatch_(a)sync效果一樣。
既然在序列佇列上跟dispatch_(a)sync效果一樣,那就要小心別死鎖!
dispatch_set_context與dispatch_set_finalizer_f的配合使用
dispatch_set_context可以為佇列新增上下文資料,但是因為GCD是C語言介面形式的,所以其context引數型別是“void *”。也就是說,我們建立context時有如下幾種選擇:
用C語言的malloc建立context資料。
用C++的new建立類物件。
用Objective-C的物件,但是要用__bridge等關鍵字轉為Core Foundation物件。
以上所有建立context的方法都有一個必須的要求,就是都要釋放記憶體!,無論是用free、delete還是CF的CFRelease,我們都要確保在佇列不用的時候,釋放context的記憶體,否則就會造成記憶體洩露。
所以,使用dispatch_set_context的時候,最好結合dispatch_set_finalizer_f使用,為佇列設定“解構函式”,在這個函式裡面釋放記憶體,大致如下:
void cleanStaff(void *context) {
//釋放context的記憶體!
//CFRelease(context);
//free(context);
//delete context;
}
…
//在佇列建立後,設定其“解構函式”
dispatch_set_finalizer_f(queue, cleanStaff);
詳細用法,請看我之前寫的Blog為GCD佇列繫結NSObject型別上下文資料-利用__bridge_retained(transfer)轉移記憶體管理權
總結
其實本文更像是總結了GCD中的“坑”=。=
至於經驗,總結一條,就是使用任何技術,都要研究透徹,否則後患無窮啊~
參考
Grand Central Dispatch (GCD) Reference
Concurrency Programming Guide
Using Dispatch Groups to Wait for Multiple Web Services