iOS 多線程相關(guān)

概念

在開始多線程之前，我們先來了解幾個比較容易混淆的概念。

線程與進程

一個進程，可以擁有一個或多個線程。

runloop與線程

http://www.itdecent.cn/p/9a46e6762fca

并發(fā)與并行

并發(fā)指多個任務交替占用CPU，并行指多個CPU同時執(zhí)行多個任務。好比在火車站買票，并發(fā)是指一個窗口有多人排隊買票，并行是指多個窗口有多人排隊買票。

同步和異步

同步指在執(zhí)行一個函數(shù)時，如果這個函數(shù)沒有執(zhí)行完畢，那么下一個函數(shù)便不能執(zhí)行。異步指在執(zhí)行一個函數(shù)時，不必等到這個函數(shù)執(zhí)行完畢，便可開始執(zhí)行下一個函數(shù)。

四種方式

iOS目前有四種多線程方式：

  • Pthreads
  • NSThread
  • GCD
  • NSOperation & NSOperationQueue

Pthreads

這個方法不必多說，大家了解一下就好，按照百度百科里的解釋：

POSIX線程（POSIX threads），簡稱Pthreads，是線程的POSIX標準。該標準定義了創(chuàng)建和操縱線程的一整套API。在類Unix操作系統(tǒng)（Unix、Linux、Mac OS X等）中，都使用Pthreads作為操作系統(tǒng)的線程。

簡單的說，這是一套在很多操作系統(tǒng)上都適用的多線程API，所以移植性很強（然并卵）。雖然它在iOS系統(tǒng)中是適用的，但它是基于c語言的框架，用起來是相當?shù)乃崴ㄐ枰绦騿T自己管理線程的生命周期），下面可以來體驗一下：

- (void)threads {
    // 定義一個pthread_t類型的變量
    pthread_t thread;
    // 創(chuàng)建一個線程，并自動運行
    pthread_create(&thread, NULL, run, NULL);
    // 設(shè)置該線程的狀態(tài)為detached，該線程結(jié)束后會自動釋放所有資源
    pthread_detach(thread);
}
void *run(void *data) { // 新線程調(diào)用的方法，里面有需要執(zhí)行的任務
    NSLog(@"%@", [NSThread currentThread]);
    return NULL;
}

打印結(jié)果：

2019-05-30 22:25:55.516777+0800 studyDemo[46180:3419195] <NSThread: 0x6000014ffac0>{number = 3, name = (null)}

NSThread

這套方案是經(jīng)過蘋果封裝后的，并且完全面向?qū)ο蟮?。所以可以直接操控線程對象，非常直觀和方便。但是它的生命周期還是需要手動管理，所以使用較少。比如[NSThread currentThread]，它可以獲取當前線程類，從而可以知道當前線程的各種屬性，用于調(diào)試非常方便。下面來看代碼：

- (void)threads_NSThread {
    // 創(chuàng)建
    NSThread *thread = [[NSThread alloc] initWithTarget:self selector:@selector(threadLog) object:nil];
    // 啟動
    [thread start];

    // 創(chuàng)建并啟動
    [NSThread detachNewThreadSelector:@selector(threadLog) toTarget:self withObject:nil];
}
- (void)threadLog {
    NSLog(@"%@", [NSThread currentThread]);
}

打印結(jié)果：

2019-05-30 22:39:37.926337+0800 studyDemo[46421:3427904] <NSThread: 0x6000029c10c0>{number = 3, name = (null)}

GCD

同步

let queue = DispatchQueue(label: "com.ffib.blog")

queue.sync {
    for i in 0..<5 {
        print(i)
    }
}

for i in 10..<15 {
    print(i)
}

output: 
0
1
2
3
4
10
11
12
13
14

從結(jié)果可以看出隊列同步操作時，當程序在進行隊列任務時，主線程的操作并不會被執(zhí)行，這是由于當程序在執(zhí)行同步操作時，會阻塞線程，所以需要等待隊列任務執(zhí)行完畢，程序才可以繼續(xù)執(zhí)行。

異步

let queue = DispatchQueue(label: "com.ffib.blog")

queue.async {
    for i in 0..<5 {
        print(i)
    }
}

for i in 10..<15 {
    print(i)
}

output:
10
11
12
13
14
0
1
2
3
4

從結(jié)果可以看出隊列異步操作時，當程序在執(zhí)行隊列任務時，不必等待隊列任務開始執(zhí)行，便可執(zhí)行主線程的操作。與同步執(zhí)行相比，異步隊列并不會阻塞主線程，當主線程空閑時，便可執(zhí)行別的任務。

QoS 優(yōu)先級

在實際開發(fā)中，我們需要對任務分類，比如UI的顯示和交互操作等，屬于優(yōu)先級比較高的，有些不著急操作的，比如緩存操作、用戶習慣收集等，相對來說優(yōu)先級比較低。
在GCD中，我們使用隊列和優(yōu)先級劃分任務，以達到更好的用戶體驗，選擇合適的優(yōu)先級，可以更好的分配CPU的資源。
GCD內(nèi)采用DispatchQoS結(jié)構(gòu)體，如果沒有指定QoS，會使用default。
以下等級由高到低。

public struct DispatchQoS : Equatable {

     public static let userInteractive: DispatchQoS //用戶交互級別，需要在極快時間內(nèi)完成的，例如UI的顯示
     
     public static let userInitiated: DispatchQoS  //用戶發(fā)起，需要在很快時間內(nèi)完成的，例如用戶的點擊事件、以及用戶的手勢
     。
     public static let `default`: DispatchQoS  //系統(tǒng)默認的優(yōu)先級，與主線程優(yōu)先級一致
     
     public static let utility: DispatchQoS   //實用級別，不需要很快完成的任務
     
     public static let background: DispatchQoS  //用戶無法感知，比較耗時的一些操作

     public static let unspecified: DispatchQoS
}

以下通過兩個例子來具體看一下優(yōu)先級的使用。
相同優(yōu)先級

let queue1 = DispatchQueue(label: "com.ffib.blog.queue1", qos: .utility)
let queue2 = DispatchQueue(label: "com.ffib.blog.queue2", qos: .utility)

queue1.async {
    for i in 5..<10 {
        print(i)
    }
}

queue2.async {
    for i in 0..<5 {
        print(i)
    }
}
 output:
 0
 5
 1
 6
 2
 7
 3
 8
 4
 9

從結(jié)果可見，優(yōu)先級相同時，兩個隊列是交替執(zhí)行的。

不同優(yōu)先級

let queue1 = DispatchQueue(label: "com.ffib.blog.queue1", qos: .default)
let queue2 = DispatchQueue(label: "com.ffib.blog.queue2", qos: .utility)

queue1.async {
    for i in 0..<5 {
        print(i)
    }
}

queue2.async {
    for i in 5..<10 {
        print(i)
    }
}

output:
0
1
2
3
4
5
6
7
8
9

從結(jié)果可見，CPU會把更多的資源優(yōu)先分配給優(yōu)先級高的隊列，等到CPU空閑之后才會分配資源給優(yōu)先級低的隊列。

主隊列默認使用擁有最高優(yōu)先級，即userInteractive，所以慎用這一優(yōu)先級，否則極有可能會影響用戶體驗。
一些不需要用戶感知的操作，例如緩存等，使用utility即可

串行隊列

在創(chuàng)建隊列時，不指定隊列類型時，默認為串行隊列。

let queue = DispatchQueue(label: "com.ffib.blog.initiallyInactive.queue", qos: .utility)

queue.async {
    for i in 0..<5 {
        print(i)
    }
}

queue.async {
    for i in 5..<10 {
        print(i)
    }
}

queue.async {
    for i in 10..<15 {
        print(i)
    }
}
output: 
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

從結(jié)果可見隊列執(zhí)行結(jié)果，是按任務添加的順序，依次執(zhí)行。

并行隊列

let queue = DispatchQueue(label: "com.ffib.blog.concurrent.queue", qos: .utility, attributes: .concurrent)

queue.async {
    for i in 0..<5 {
        print(i)
    }
}

queue.async {
    for i in 5..<10 {
        print(i)
    }
}

queue.async {
    for i in 10..<15 {
        print(i)
    }
}
output:
5
0
10
1
2
3
11
4
6
12
7
13
8
14
9

從結(jié)果可見，所有任務是以并行的狀態(tài)執(zhí)行的。另外在設(shè)置attributes參數(shù)時，參數(shù)還有另一個枚舉值initiallyInactive，表示的任務不會自動執(zhí)行，需要程序員去手動觸發(fā)(queue.activate())。如果不設(shè)置，默認是添加完任務后，自動執(zhí)行。
添加initiallyInactive這一屬性帶來了，更多的靈活性，可以自由的決定執(zhí)行的時機。

再來看看并行隊列如何設(shè)置這一枚舉值。

let queue = DispatchQueue.init(label: "Qos5", qos: .utility, attributes: [.concurrent, .initiallyInactive])

延遲執(zhí)行

GCD提供了任務延時執(zhí)行的方法，通過對已創(chuàng)建的隊列，調(diào)用延時任務的函數(shù)即可。其中時間以DispatchTimeInterval設(shè)置，GCD內(nèi)跟時間參數(shù)有關(guān)系的參數(shù)都是通過這一枚舉來設(shè)置。

public enum DispatchTimeInterval : Equatable {

    case seconds(Int)     //秒

    case milliseconds(Int) //毫秒

    case microseconds(Int) //微妙

    case nanoseconds(Int)  //納秒

    case never
}

在設(shè)置調(diào)用函數(shù)時，asyncAfter有兩個及其相同的方法，不同的地方在于參數(shù)名有所不同，參照Stack Overflow的解釋。

wallDeadline 和 deadline，當系統(tǒng)睡眠后,wallDeadline會繼續(xù)，但是deadline會被掛起。例如：設(shè)置參數(shù)為60分鐘，當系統(tǒng)睡眠50分鐘，wallDeadline會在系統(tǒng)醒來之后10分鐘執(zhí)行，而deadline會在系統(tǒng)醒來之后60分鐘執(zhí)行。

let queue = DispatchQueue(label: "com.ffib.blog.after.queue")

let time = DispatchTimeInterval.seconds(5)

queue.asyncAfter(wallDeadline: .now() + time) {
    print("wall dead line done")
}

queue.asyncAfter(deadline: .now() + time) {
    print("dead line done")
}

DispatchQueue.main.asyncAfter(deadline: .now() + Double(NSEC_PER_SEC * 1) / Double(NSEC_PER_SEC)) {
    print("主線程 dead line done")
}

dispatch_group (組)

如果想等到所有的隊列的任務執(zhí)行完畢再進行某些操作時，可以使用DispatchGroup來完成。

let group = DispatchGroup()
let queue1 = DispatchQueue(label: "com.ffib.blog.queue1", qos: .utility)
let queue2 = DispatchQueue(label: "com.ffib.blog.queue2", qos: .utility)
queue1.async(group: group) {
    for i in 0..<5 {
        print(i)
    }
}
queue2.async(group: group) {
    for i in 6..<10 {
        print(i)
    }
}

//group內(nèi)所有線程的任務執(zhí)行完畢
group.notify(queue: DispatchQueue.main) {
    print("done")
}

output: 
5
0
6
1
7
2
8
3
9
4
done

如果想等待某一隊列先執(zhí)行完畢再執(zhí)行其他隊列可以使用wait

group.wait()
// 上方的output會變?yōu)椋?~9 done，因為wait會同步等待先前提交的工作完成。（類似同步執(zhí)行）

為防止隊列執(zhí)行任務時出現(xiàn)阻塞，導致線程鎖死，可以設(shè)置超時時間。

// 同步等待先前提交的工作完成，如果在指定的超時時間之前工作未完成，則返回。
group.wait(timeout: <#T##DispatchTime#>) 
// 作用同上，DispatchTime為主板時間CPU時鐘計時, DispatchWallTime為實際時間即系統(tǒng)時間
group.wait(wallTimeout: <#T##DispatchWallTime#>)

DispatchWorkItem

Swift3新增的api，可以通過此api設(shè)置隊列執(zhí)行的任務。先看看簡單應用吧。通過DispatchWorkItem初始化閉包。

let workItem = DispatchWorkItem {
    for i in 0..<10 {
        print(i)
    }
}

調(diào)用一共分兩種情況，第一種是通過調(diào)用perform()，自動響應閉包。

 DispatchQueue.global().async {
     workItem.perform()
 }

第二種是作為參數(shù)傳給async方法。

 DispatchQueue.global().async(execute: workItem)

接下來我們來看看DispatchWorkItem的內(nèi)部都有些什么方法和屬性。

init(qos: DispatchQoS = default, flags: DispatchWorkItemFlags = default,
    block: @escaping () -> Void)

從初始化方法開始，DispatchWorkItem也可以設(shè)置優(yōu)先級，另外還有個參數(shù)DispatchWorkItemFlags，來看看DispatchWorkItemFlags的內(nèi)部組成。

public struct DispatchWorkItemFlags : OptionSet, RawRepresentable {

    public static let barrier: DispatchWorkItemFlags 

    public static let detached: DispatchWorkItemFlags

    public static let assignCurrentContext: DispatchWorkItemFlags

    public static let noQoS: DispatchWorkItemFlags

    public static let inheritQoS: DispatchWorkItemFlags

    public static let enforceQoS: DispatchWorkItemFlags
}

DispatchWorkItemFlags主要分為兩部分：

  • 覆蓋
    • noQoS 沒有優(yōu)先級
    • inheritQoS 繼承Queue的優(yōu)先級
    • enforceQoS 覆蓋Queue的優(yōu)先級
  • 執(zhí)行情況
    • barrier
    • detached
    • assignCurrentContext

執(zhí)行情況會在下文會具體描述，先在這留個坑。
先來看看設(shè)置優(yōu)先級，會對任務執(zhí)行有什么影響。

let queue1 = DispatchQueue(label: "com.ffib.blog.workItem1", qos: .utility)
let queue2 = DispatchQueue(label: "com.ffib.blog.workItem2", qos: .userInitiated)
let workItem1 = DispatchWorkItem(qos: .userInitiated) {
    for i in 0..<5 {
        print(i)
    }
}
let workItem2 = DispatchWorkItem(qos: .utility) {
    for i in 5..<10 {
        print(i)
    }
}
queue1.async(execute: workItem1)
queue2.async(execute: workItem2)

output:
5
6
7
8
9
0
1
2
3
4

由結(jié)果可見即使設(shè)置了DispatchWorkItem僅僅只設(shè)置了優(yōu)先級并不會對任務執(zhí)行順序有任何影響。也就是仍然按照queue的優(yōu)先級執(zhí)行。
接下來，再來設(shè)置DispatchWorkItemFlags試試

let queue1 = DispatchQueue(label: "com.ffib.blog.workItem1", qos: .utility)
let queue2 = DispatchQueue(label: "com.ffib.blog.workItem2", qos: .userInitiated)

let workItem1 = DispatchWorkItem(qos: .userInitiated, flags: .enforceQoS) {
    for i in 0..<5 {
        print(i)
    }
}

let workItem2 = DispatchWorkItem {
    for i in 5..<10 {
        print(i)
    }
}

queue1.async(execute: workItem1)
queue2.async(execute: workItem2)
output:
5
0
6
1
7
2
8
3
9
4

設(shè)置enforceQoS，使優(yōu)先級強制覆蓋queue的優(yōu)先級，所以兩個隊列呈交替執(zhí)行狀態(tài)，變?yōu)橥粌?yōu)先級。
DispatchWorkItem也有wait和notify方法，和DispatchGroup用法相同。wait會等待這個workItem執(zhí)行完畢。會阻塞當前線程。也可以使用cancel()提前取消任務。

// 執(zhí)行結(jié)束通過notify提示主隊列
workItem.notify(queue: DispatchQueue.main) {
    print("value = ", value)
}

// wait會等待這個workItem執(zhí)行完畢。會阻塞當前線程。workItem3會先執(zhí)行完，之后再執(zhí)行workItem2
queue12.async(execute: workItem4)
queue13.async(execute: workItem3)
workItem3.wait()

dispatch_once (單次)

一般用于單例

// swift
class Tool: NSObject {
    static let share = Tool()
}

// OC
// Tool.h
@interface Tool : NSObject
+ (instancetype)sharedInstance;
@end
// Tool.m
@implementation Tool
+ (instancetype)sharedInstance {    
    static Tool *instance;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        instance = [[self alloc] init];
    });
    return instance;
}
@end

DispatchSemaphore(信號量)

如果你想同步執(zhí)行一個異步隊列任務，可以使用信號量。
wait()會使信號量減一，如果信號量大于1則會返回.success，否則返回timeout（超時），也可以設(shè)置超時時間。

func wait(wallTimeout: DispatchWallTime) -> DispatchTimeoutResult
func wait(timeout: DispatchTime) -> DispatchTimeoutResult

signal()會使信號量加一，返回當前信號量。

print("DispatchSemaphore: 開始")
let semaphore = DispatchSemaphore.init(value: 1)
let queue = DispatchQueue.init(label: "semaphore0", qos: .utility)

for i in 0 ..< 5 {
    print("wait: \(i)")
    if semaphore.wait(timeout: .distantFuture) == .success {
        queue.async {
            sleep(2)
            print("semaphore: \(semaphore.signal())、\(i)")
        }
    }
}
print("DispatchSemaphore: 結(jié)束")

output:
DispatchSemaphore: 開始
wait: 0
wait: 1
semaphore: 1、0
wait: 2
semaphore: 1、1
wait: 3
semaphore: 1、2
wait: 4
semaphore: 1、3
DispatchSemaphore: 結(jié)束
semaphore: 0、4

我們來看下for循環(huán)里都發(fā)生了什么。第一遍循環(huán)遇到wait時，此時信號量為1，大于0，所以if判斷為true，進行sleep和打印操作；當?shù)诙檠h(huán)遇到wait時，發(fā)現(xiàn)信號量為0，此時就會鎖死線程，直到上一遍循環(huán)的操作完成，調(diào)用signal()方法，信號量加一，才會繼續(xù)執(zhí)行操作，循環(huán)以上操作。

DispatchSemaphore還有另外一個用法，可以限制隊列的最大并發(fā)量，通過前面所說的wait()信號量減一，signal()信號量加一，來完成此操作，正如上文所述例子，其實達到的效果就是最大并發(fā)量為一。
如果使用過NSOperationQueue的同學，應該知道m(xù)axConcurrentOperationCount，效果是類似的。

DispatchWorkItemFlags

barrier可以理解為隔離，在讀取時，可以異步訪問，但是如果突然出現(xiàn)了異步寫入操作，我們想要達到的效果是在進行寫入操作的時候，使讀取操作暫停，直到寫入操作結(jié)束，再繼續(xù)進行讀取操作，以保證讀取操作獲取的是最新內(nèi)容。
預期結(jié)果是：在寫入操作之前，讀取到的內(nèi)容是a；在寫入操作之后，讀取到的內(nèi)容是b（即寫入的內(nèi)容）。
先看看不使用barrier的結(jié)果。

print("DispatchWorkItemFlags: 開始")
var testStr = "a"
let queue1 = DispatchQueue.init(label: "flags", attributes: .concurrent)
let readWorkItem = DispatchWorkItem.init {
    sleep(1)
    print(testStr)
}
let writeWorkItem = DispatchWorkItem.init {
    sleep(3)
    testStr = "b"
    print("write")
}
queue1.async(execute: readWorkItem)
queue1.async(execute: writeWorkItem)
queue1.async(execute: readWorkItem)
print("DispatchWorkItemFlags: 結(jié)束")
output：
DispatchWorkItemFlags: 開始
DispatchWorkItemFlags: 結(jié)束
a
a
write

結(jié)果不是我們想要的。再來看看加了barrier之后的效果。

// 將上題writeWorkItem修改初始化方式
let writeWorkItem = DispatchWorkItem.init(flags: [.barrier]) {
    // 里面內(nèi)容同上，不變
}
output：
DispatchWorkItemFlags: 開始
DispatchWorkItemFlags: 結(jié)束
a
write
b

結(jié)果符合預期的想法，barrier主要用于讀寫隔離，以保證寫入的時候，不被讀取。

dispatch_barrier_async (柵欄)

釋義

void dispatch_barrier_async(dispatch_queue_t queue, dispatch_block_t block);

dispatch_barrier_async一般叫做“柵欄函數(shù)”，它就好像柵欄一樣可以將多個操作分隔開，在它前面追加的操作先執(zhí)行，在它后面追加的操作后執(zhí)行。
柵欄函數(shù)也可以執(zhí)行隊列上的操作(參數(shù)列表中有queue和block)，也有對應的 dispatch_barrier_sync 函數(shù)。

示例：

- (void)testBarrierAsync
{
    //創(chuàng)建一個并行隊列
    dispatch_queue_t concurrentQueue = dispatch_queue_create("com.gcd.barrier.concurrentQueue", DISPATCH_QUEUE_CONCURRENT);
    
    //并行操作
    void (^blk1)() = ^{
        NSLog(@"1");
    };
    void (^blk2)() = ^{
        NSLog(@"2");
    };
    void (^blk3)() = ^{
        NSLog(@"3");
    };
    void (^blk4)() = ^{
        NSLog(@"4");
    };
    void (^blk5)() = ^{
        NSLog(@"5");
    };
    void (^blk6)() = ^{
        NSLog(@"6");
    };
    
    //柵欄函數(shù)執(zhí)行操作
    void (^barrierBlk)() = ^{
        NSLog(@"Barrier!");
    };
    
    //執(zhí)行所有操作
    dispatch_async(concurrentQueue, blk1);
    dispatch_async(concurrentQueue, blk2);
    dispatch_async(concurrentQueue, blk3);
    dispatch_barrier_async(concurrentQueue, barrierBlk);
    dispatch_async(concurrentQueue, blk4);
    dispatch_async(concurrentQueue, blk5);
    dispatch_async(concurrentQueue, blk6);
}

方法執(zhí)行結(jié)果：

 2
 1
 3
 Barrier!
 5
 4
 6

分析：
柵欄函數(shù)之前和之后的操作執(zhí)行順序都不固定，但是前面三個必然先執(zhí)行，然后再執(zhí)行柵欄函數(shù)中的操作，最后執(zhí)行后面的三個。
注意：
dispatch_barrier_async(dispatch_queue_t queue, dispatch_block_t block)

柵欄函數(shù)中傳入的參數(shù)隊列必須是由 dispatch_queue_create 方法創(chuàng)建的隊列，否則，與dispatch_async無異，起不到“柵欄”的作用了，對于dispatch_barrier_sync也是同理。

參考文獻

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關(guān)閱讀更多精彩內(nèi)容

  • 本篇涵蓋多線程解析、應用等. 1.iOS多線程--徹底學會多線程之『RunLoop』2.iOS多線程--徹底學會多...
    守護地中海的花閱讀 208評論 0贊 3
  • iOS多線程 相關(guān)概念 1. 進程：進程(process):是指在系統(tǒng)中正在獨立運行的一個應用程序. 比如同時打開...
    smile麗語閱讀 346評論 0贊 3
  • 作為一個程序員，經(jīng)常要與程序打交道。如何讓你的程序更加健壯，已經(jīng)成為一個繞不開的話題，除了讓代碼本身的邏輯更加清晰...
    404ErrorCrash閱讀 356評論 0贊 0
  • performSelector 需要注意的是：如果是帶afterDelay的延時函數(shù)，會在內(nèi)部創(chuàng)建一個NSTime...
    72行代碼閱讀 1,051評論 0贊 1
  • 久違的晴天，家長會。 家長大會開好到教室時，離放學已經(jīng)沒多少時間了。班主任說已經(jīng)安排了三個家長分享經(jīng)驗。 放學鈴聲...
    飄雪兒5閱讀 7,788評論 16贊 22

友情鏈接更多精彩內(nèi)容