iOS多執行緒的鎖,你知道多少？-有解無憂

前言

iOS開發中由于各種第三方庫的高度封裝，對鎖的使用很少，剛好之前面試中被問到的關于并發編程鎖的問題，都是一知半解，于是決定整理一下關于iOS中鎖的知識，為大家查缺補漏，

正文

一、什么是鎖

在過去幾十年并發研究領域的出版物中，鎖總是扮演著壞人的角色，鎖背負的指控包括引起死鎖、鎖封護（luyang注：lock convoying，多個同優先級的執行緒重復競爭同一把鎖，此時大量雖然被喚醒而得不到鎖的執行緒被迫進行調度切換，這種頻繁的調度切換相當影響系統性能）、饑餓、不公平、data races以及其他許多并發帶來的罪孽，有趣的是，在共享記憶體并行軟體中真正承擔重擔的是——你猜對了——鎖，

在計算機科學中，鎖是一種同步機制，用于多執行緒環境中對資源訪問的限制，你可以理解成它用于排除并發的一種策略，

    if (lock == 0) {
        lock = myPID;
    }復制代碼

上面這段代碼并不能保證這個任務有鎖，因此它可以在同一時間被多個任務執行，這個時候就有可能多個任務都檢測到lock是空閑的，因此兩個或者多個任務都將嘗試設定lock，而不知道其他的任務也在嘗試設定lock，這個時候就會出問題了，再看看下面這段代碼(Swift)：

    class Account {
    private(set) var val: Int = 0 //這里不可在其他方法修改，只能通過add/minus修改
    public func add(x: Int) {
        objc_sync_enter(self)
        defer {
            objc_sync_exit(self)
        }
        val += x
    }

    public func minus(x: Int) {
        objc_sync_enter(self)
        defer {
            objc_sync_exit(self)
        }
        val -= x;
    }
}復制代碼

這樣就能防止多個任務去修改val了，

二、鎖的分類

鎖根據不同的性質可以分成不同的類，

在WiKiPedia介紹中，一般的鎖都是建議鎖，也就四每個任務去訪問公共資源的時候，都需要取得鎖的資訊，再根據鎖資訊來確定是否可以存取，若存取對應資訊，鎖的狀態會改變為鎖定，因此其他執行緒不會訪問該資源，當結束訪問時，鎖會釋放，允許其他任務訪問，有些系統有強制鎖，若未經授權的鎖訪問鎖定的資料，在訪問時就會產生例外，

在iOS中，鎖分為互斥鎖、遞回鎖、信號量、條件鎖、自旋鎖、讀寫鎖（一種特所的自旋鎖）、分布式鎖，

對于資料庫的鎖分類：

分類方式	分類
按鎖的粒度劃分	表級鎖、行級鎖、頁級鎖
按鎖的級別劃分	共享鎖、排他鎖
按加鎖的方式劃分	自動鎖、顯示鎖
按鎖的使用方式劃分	樂觀鎖、悲觀鎖
按操作劃分	DML鎖、DDL鎖

這里就不再詳細的介紹了，感興趣的大家可以帶Wiki
查閱相關資料，

1、互斥鎖

在編程中，引入物件互斥鎖的概念，來保證共享資料操作的完整性，每個物件都對應于一個可稱為“互斥鎖”的標記，這個標記用來保證在任一時刻，只能有一個執行緒訪問物件，

1.1 @synchronized

@synchronized要一個引數，這個引數相當于信號量

// 用在防止多執行緒訪問屬性上比較多
- (void)setTestInt:(NSInteger)testInt {
    @synchronized (self) {
        _testInt = testInt;
    }
}復制代碼

1.2 NSLock

block及宏定義

// 定義block型別
typedef void(^MMBlock)(void);

// 定義獲取全域佇列方法
#define MM_GLOBAL_QUEUE(block) \
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ \
    while (1) { \
        block();\
    }\
})復制代碼

測驗代碼

NSLock *lock = [[NSLock alloc] init];
MMBlock block = ^{
    [lock lock];
    NSLog(@"執行操作");
    sleep(1);
    [lock unlock];
};
MM_GLOBAL_QUEUE(block);復制代碼

1.3 pthread

pthread除了創建互斥鎖，還可以創建遞回鎖、讀寫鎖、once等鎖，稍后會介紹一下如何使用，如果想要深入學習pthread請查閱相關檔案、資料單獨學習，

靜態初始化： pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER
動態初始化： pthread_mutex_init() 函式是以動態方式創建互斥鎖的，引數 attr 指定了新建互斥鎖的屬性，如果引數 attr 為 NULL ,使用默認的屬性，回傳0代表初始化成功，這種方式可以初始化普通鎖、遞回鎖(同 NSRecursiveLock ), 初始化方式有些復雜，
此類初始化方法可設定鎖的型別，PTHREAD_MUTEX_ERRORCHECK 互斥鎖不會檢測死鎖， PTHREAD_MUTEX_ERRORCHECK 互斥鎖可提供錯誤檢查， PTHREAD_MUTEX_RECURSIVE 遞回鎖， PTHREAD_PROCESS_DEFAULT 映射到 PTHREAD_PROCESS_NORMAL.
下面是我從YYKitcopy下來的：

#import <pthread.h>

//YYKit
static inline void pthread_mutex_init_recursive(pthread_mutex_t *mutex, bool recursive) {
#define YYMUTEX_ASSERT_ON_ERROR(x_) do { \
__unused volatile int res = (x_); \
assert(res == 0); \
} while (0)
    assert(mutex != NULL);
    if (!recursive) {
        //普通鎖
        YYMUTEX_ASSERT_ON_ERROR(pthread_mutex_init(mutex, NULL));
    } else {
        //遞回鎖
        pthread_mutexattr_t attr;
        YYMUTEX_ASSERT_ON_ERROR(pthread_mutexattr_init (&attr));
        YYMUTEX_ASSERT_ON_ERROR(pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_RECURSIVE));
        YYMUTEX_ASSERT_ON_ERROR(pthread_mutex_init (mutex, &attr));
        YYMUTEX_ASSERT_ON_ERROR(pthread_mutexattr_destroy (&attr));
    }
#undef YYMUTEX_ASSERT_ON_ERROR
}復制代碼

測驗代碼

__block pthread_mutex_t lock;
    pthread_mutex_init_recursive(&lock,false);

    MMBlock block0=^{
        NSLog(@"執行緒 0：加鎖");
        pthread_mutex_lock(&lock);
        NSLog(@"執行緒 0：睡眠 1 秒");
        sleep(1);
        pthread_mutex_unlock(&lock);
        NSLog(@"執行緒 0：解鎖");
    };
    MM_GLOBAL_QUEUE(block0);

    MMBlock block1=^(){
        NSLog(@"執行緒 1：加鎖");
        pthread_mutex_lock(&lock);
        NSLog(@"執行緒 1：睡眠 2 秒");
        sleep(2);
        pthread_mutex_unlock(&lock);
        NSLog(@"執行緒 1：解鎖");
    };
    MM_GLOBAL_QUEUE(block1);

    MMBlock block2=^{
        NSLog(@"執行緒 2：加鎖");
        pthread_mutex_lock(&lock);
        NSLog(@"執行緒 2：睡眠 3 秒");
        sleep(3);
        pthread_mutex_unlock(&lock);
        NSLog(@"執行緒 2：解鎖");
    };
    MM_GLOBAL_QUEUE(block2);復制代碼

輸出結果：

 執行緒 2：加鎖
 執行緒 0：加鎖
 執行緒 1：加鎖
 執行緒 2：睡眠 3 秒復制代碼

 執行緒 2：加鎖
 執行緒 0：加鎖
 執行緒 1：加鎖
 執行緒 2：睡眠 3 秒
 執行緒 2：解鎖
 執行緒 0：睡眠 1 秒
 執行緒 2：加鎖復制代碼

 執行緒 2：加鎖
 執行緒 0：加鎖
 執行緒 1：加鎖
 執行緒 2：睡眠 3 秒
 執行緒 2：解鎖
 執行緒 0：睡眠 1 秒
 執行緒 2：加鎖
 執行緒 0：解鎖
 執行緒 1：睡眠 2 秒
 執行緒 0：加鎖復制代碼

2、遞回鎖

同一個執行緒可以多次加鎖，不會造成死鎖

舉個🌰：

NSLock *lock = [[NSLock alloc] init];

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

    static void (^RecursiveMethod)(int);

    RecursiveMethod = ^(int value) {

        [lock lock];
        if (value > 0) {

            NSLog(@"value = %d", value);
            sleep(2);
            RecursiveMethod(value - 1);
        }
        [lock unlock];
    };

    RecursiveMethod(5);
});復制代碼

這段代碼是一個典型的死鎖情況，在我們的執行緒中，RecursiveMethod是遞回呼叫的，所有每次進入這個block時，都會去加一次鎖，而從第二次開始，由于鎖已經被使用了且沒有解鎖，所有它需要等待鎖被解除，這樣就導致了死鎖，執行緒被阻塞住了，控制臺會輸出如下資訊：

value = 5
*** -[NSLock lock]: deadlock ( '(null)')   *** Break on _NSLockError() to debug.復制代碼

2.1 NSRecursiveLock

實作代碼

NSRecursiveLock *lock = [[NSRecursiveLock alloc] init];
    MM_GLOBAL_QUEUE(^{
        static void (^RecursiveBlock)(int);
        RecursiveBlock = ^(int value) {
            [lock lock];
            if (value > 0) {
                NSLog(@"加鎖層數 %d", value);
                sleep(1);
                RecursiveBlock(--value);
            }
            [lock unlock];
        };
        RecursiveBlock(3);
    });復制代碼

輸出結果(從輸出結果可以看出并未發生死鎖)：

加鎖層數 3
加鎖層數 2
加鎖層數 1
加鎖層數 3
加鎖層數 2
加鎖層數 1
加鎖層數 3
加鎖層數 2復制代碼

2.2 pthread

代碼實作

__block pthread_mutex_t lock;
    //第二個引數為true生成遞回鎖
    pthread_mutex_init_recursive(&lock,true);

    MM_GLOBAL_QUEUE(^{
        static void (^RecursiveBlock)(int);
        RecursiveBlock = ^(int value) {
            pthread_mutex_lock(&lock);
            if (value > 0) {
                NSLog(@"加鎖層數 %d", value);
                sleep(1);
                RecursiveBlock(--value);
            }
            pthread_mutex_unlock(&lock);
        };
        RecursiveBlock(3);
    });復制代碼

輸出結果(同樣，結果顯示并未發生死鎖)：

加鎖層數 3
加鎖層數 2
加鎖層數 1
加鎖層數 3
加鎖層數 2
加鎖層數 1
加鎖層數 3
加鎖層數 2復制代碼

3、信號量

信號量(Semaphore)，有時被稱為信號燈，是在多執行緒環境下使用的一種設施，是可以用來保證兩個或多個關鍵代碼段不被并發呼叫，在進入一個關鍵代碼段之前，執行緒必須獲取一個信號量；一旦該關鍵代碼段完成了，那么該執行緒必須釋放信號量，其它想進入該關鍵代碼段的執行緒必須等待直到第一個執行緒釋放信號量

3.1 dispatch_semaphore_t

同步實作

// 引數可以理解為信號的總量，傳入的值必須大于或等于0，否則，回傳NULL
// dispatch_semaphore_signal + 1
// dispatch_semaphore_wait等待信號，當 <= 0會進入等待狀態
__block dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);
MM_GLOBAL_QUEUE(^{
        dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
        NSLog(@"這里簡單寫一下用法，可自行實作生產者、消費者");
        sleep(1);
        dispatch_semaphore_signal(semaphore);
    });復制代碼

3.2 pthread

測驗代碼

__block pthread_mutex_t mutex=PTHREAD_MUTEX_INITIALIZER;
    __block pthread_cond_t cond=PTHREAD_COND_INITIALIZER;

    MM_GLOBAL_QUEUE(^{
        //NSLog(@"執行緒 0：加鎖");
        pthread_mutex_lock(&mutex);
        pthread_cond_wait(&cond, &mutex);
        NSLog(@"執行緒 0：wait");
        pthread_mutex_unlock(&mutex);
        //NSLog(@"執行緒 0：解鎖");
    });

    MM_GLOBAL_QUEUE(^{
        //NSLog(@"執行緒 1：加鎖");
        sleep(3);//3秒發一次信號
        pthread_mutex_lock(&mutex);
        NSLog(@"執行緒 1：signal");
        pthread_cond_signal(&cond);
        pthread_mutex_unlock(&mutex);
        //NSLog(@"執行緒 1：加鎖");
    });復制代碼

4、條件鎖

3.1 NSCodition

NSCondition 的物件實際上作為一個鎖和一個執行緒檢查器：鎖主要為了當檢測條件時保護資料源，執行條件引發的任務；執行緒檢查器主要是根據條件決定是否繼續運行執行緒，即執行緒是否被阻塞，

NSCondition同樣實作了NSLocking協議，所以它和NSLock一樣，也有NSLocking協議的lock和unlock方法，可以當做NSLock來使用解決執行緒同步問題，用法完全一樣，

- (void)getIamgeName:(NSMutableArray *)imageNames{
      NSCondition *lock = [[NSCondition alloc] init];
    NSString *imageName;
    [lock lock];
    if (imageNames.count>0) {
        imageName = [imageNames lastObject];
        [imageNames removeObject:imageName];
    }
    [lock unlock];
}復制代碼

同時，NSCondition提供更高級的用法，wait和signal，和條件信號量類似，比如我們要監聽imageNames陣列的個數，當imageNames的個數大于0的時候就執行清空操作，思路是這樣的，當imageNames個數大于0時執行清空操作，否則，wait等待執行清空操作，當imageNames個數增加的時候發生signal信號，讓等待的執行緒喚醒繼續執行，
NSCondition和NSLock、@synchronized等是不同的是，NSCondition可以給每個執行緒分別加鎖，加鎖后不影響其他執行緒進入臨界區，這是非常強大，
但是正是因為這種分別加鎖的方式，NSCondition使用wait并使用加鎖后并不能真正的解決資源的競爭，比如我們有個需求：不能讓m<0，假設當前m=0,執行緒A要判斷到m>0為假,執行等待；執行緒B執行了m=1操作，并喚醒執行緒A執行m-1操作的同時執行緒C判斷到m>0，因為他們在不同的執行緒鎖里面，同樣判斷為真也執行了m-1，這個時候執行緒A和執行緒C都會執行m-1,但是m=1，結果就會造成m=-1.
當我用陣列做洗掉試驗時，做增刪操作并不是每次都會出現，大概3-4次后會出現，單純的使用lock、unlock是沒有問題的，

- (void)executeNSCondition {
    NSCondition* lock = [[NSCondition alloc] init];

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        for (NSUInteger i=0; i<3; i++) {
            sleep(2);
            if (i == 2) {
                [lock lock];
                [lock broadcast];
                [lock unlock];
            }

        }
    });

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(1);
        [self threadMethodOfNSCodition:lock];
    });

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(1);
        [self threadMethodOfNSCodition:lock];
    });

}

-(void)threadMethodOfNSCodition:(NSCondition*)lock{
    [lock lock];
    [lock wait];
    [lock unlock];

}復制代碼

3.2 NSCoditionLock

lock不分條件，如果鎖沒被申請，直接執行代碼
unlock不會清空條件，之后滿足條件的鎖還會執行
unlockWithCondition:我的理解就是設定解鎖條件(同一時刻只有一個條件，如果已經設定條件，相當于修改條件)
lockWhenCondition:滿足特定條件,執行相應代碼
NSConditionLock同樣實作了NSLocking協議，試驗程序中發現性能很低，
NSConditionLock也可以像NSCondition一樣做多執行緒之間的任務等待呼叫，而且是執行緒安全的，

- (void)executeNSConditionLock {
    NSConditionLock* lock = [[NSConditionLock alloc] init];

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        for (NSUInteger i=0; i<3; i++) {
            sleep(2);
            if (i == 2) {
                [lock lock];
                [lock unlockWithCondition:i];
            }

        }
    });

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(1);
        [self threadMethodOfNSCoditionLock:lock];
    });

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(1);
        [self threadMethodOfNSCoditionLock:lock];
    });

}

-(void)threadMethodOfNSCoditionLock:(NSConditionLock*)lock{
    [lock lockWhenCondition:2];
    [lock unlock];

}復制代碼

3.3 POSIX Conditions

POSIX條件鎖需要互斥鎖和條件兩項來實作，雖然看起來沒有什么關系，但在運行時中，互斥鎖將會與條件結合起來，執行緒將被一個互斥和條件結合的信號來喚醒，
首先初始化條件和互斥鎖，當ready_to_go為false的時候，進入回圈，然后執行緒將會被掛起，直到另一個執行緒將ready_to_go設定為true的時候，并且發送信號的時候，該執行緒才會被喚醒，
測驗代碼

pthread_mutex_t mutex;
pthread_cond_t condition;
Boolean     ready_to_go = true;
void MyCondInitFunction()
{
    pthread_mutex_init(&mutex, NULL);
    pthread_cond_init(&condition, NULL);
}
void MyWaitOnConditionFunction()
{
    // Lock the mutex.
    pthread_mutex_lock(&mutex);
    // If the predicate is already set, then the while loop is bypassed;
    // otherwise, the thread sleeps until the predicate is set.
    while(ready_to_go == false)
    {
        pthread_cond_wait(&condition, &mutex);
    }
    // Do work. (The mutex should stay locked.)
    // Reset the predicate and release the mutex.
    ready_to_go = false;
    pthread_mutex_unlock(&mutex);
}
void SignalThreadUsingCondition()
{
    // At this point, there should be work for the other thread to do.
    pthread_mutex_lock(&mutex);
    ready_to_go = true;
    // Signal the other thread to begin work.
    pthread_cond_signal(&condition);
    pthread_mutex_unlock(&mutex);
}復制代碼

5、分布式鎖

分布式鎖是控制分布式系統之間同步訪問共享資源的一種方式，在分布式系統中，常常需要協調他們的動作，如果不同的系統或是同一個系統的不同主機之間共享了一個或一組資源，那么訪問這些資源的時候，往往需要互斥來防止彼此干擾來保證一致性，在這種情況下，便需要使用到分布式鎖，

5.1 NSDistributedLock

處理多個行程或多個程式之間互斥問題，
一個獲取鎖的行程或程式在是否鎖之前掛掉，鎖不會被釋放，可以通過breakLock方式解鎖，
iOS很少用到，暫不詳細研究，

6、讀寫鎖

讀寫鎖實際是一種特殊的自旋鎖，它把對共享資源的訪問者劃分成讀者和寫者，讀者只對共享資源進行讀訪問，寫者則需要對共享資源進行寫操作，這種鎖相對于自旋鎖而言，能提高并發性，因為在多處理器系統中，它允許同時有多個讀者來訪問共享資源，最大可能的讀者數為實際的邏輯CPU數，寫者是排他性的，一個讀寫鎖同時只能有一個寫者或多個讀者（與CPU數相關），但不能同時既有讀者又有寫者，

6.1 dispatch_barrier_async / dispatch_barrier_sync🌰

先來一個需求：假設我們原先有6個任務要執行，我們現在要插入一個任務0，這個任務0要在1、2、4都并發執行完之后才能執行，而4、5、6號任務要在這幾個任務0結束后才允許并發，大致的意思如下圖

直接上代碼：

- (void)rwLockOfBarrier {
    dispatch_queue_t queue = dispatch_queue_create("thread", DISPATCH_QUEUE_CONCURRENT);

    dispatch_async(queue, ^{
        NSLog(@"test1");
    });
    dispatch_async(queue, ^{
        NSLog(@"test2");
    });
    dispatch_async(queue, ^{
        NSLog(@"test3");
    });
    dispatch_barrier_sync(queue, ^{
        for (int i = 0; i <= 500000000; i++) {
            if (5000 == i) {
                NSLog(@"point1");
            }else if (6000 == i) {
                NSLog(@"point2");
            }else if (7000 == i) {
                NSLog(@"point3");
            }
        }
        NSLog(@"barrier");
    });
    NSLog(@"aaa");
    dispatch_async(queue, ^{
        NSLog(@"test4");
    });
    dispatch_async(queue, ^{
        NSLog(@"test5");
    });
    dispatch_async(queue, ^{
        NSLog(@"test6");
    });
}復制代碼

共同點：1、等待在它前面插入佇列的任務先執行完；2、等待他們自己的任務執行完再執行后面的任務，
不同點：1、dispatch_barrier_sync將自己的任務插入到佇列的時候，需要等待自己的任務結束之后才會繼續插入被寫在它后面的任務，然后執行它們；2、dispatch_barrier_async將自己的任務插入到佇列之后，不會等待自己的任務結束，它會繼續把后面的任務插入佇列，然后等待自己的任務結束后才執行后面的任務，

6.2 pthread

與上述初始化方式類似，靜態THREAD_RWLOCK_INITIALIZER、動態pthread_rwlock_init()、pthread_rwlock_destroy用來銷毀該鎖

#import <pthread.h>

    __block pthread_rwlock_t rwlock;
    pthread_rwlock_init(&rwlock,NULL);

    //讀
    MM_GLOBAL_QUEUE(^{
        //NSLog(@"執行緒0：隨眠 1 秒");//還是不列印能直觀些
        sleep(1);
        NSLog(@"執行緒0：加鎖");
        pthread_rwlock_rdlock(&rwlock);
        NSLog(@"執行緒0：讀");
        pthread_rwlock_unlock(&rwlock);
        NSLog(@"執行緒0：解鎖");
    });
    //寫
    MM_GLOBAL_QUEUE(^{
        //NSLog(@"執行緒1：隨眠 3 秒");
        sleep(3);
        NSLog(@"執行緒1：加鎖");
        pthread_rwlock_wrlock(&rwlock);
        NSLog(@"執行緒1：寫");
        pthread_rwlock_unlock(&rwlock);
        NSLog(@"執行緒1：解鎖");
    });復制代碼

7、自旋鎖

何謂自旋鎖？它是為實作保護共享資源而提出一種鎖機制，其實，自旋鎖與互斥鎖比較類似，它們都是為了解決對某項資源的互斥使用，無論是互斥鎖，還是自旋鎖，在任何時刻，最多只能有一個保持者，也就說，在任何時刻最多只能有一個執行單元獲得鎖，但是兩者在調度機制上略有不同，對于互斥鎖，如果資源已經被占用，資源申請者只能進入睡眠狀態，但是自旋鎖不會引起呼叫者睡眠，如果自旋鎖已經被別的執行單元保持，呼叫者就一直回圈在那里看是否該自旋鎖的保持者已經釋放了鎖，"自旋"一詞就是因此而得名，

7.1 OSSpinLock

使用方式

// 初始化
spinLock = OS_SPINKLOCK_INIT;
// 加鎖
OSSpinLockLock(&spinLock);
// 解鎖
OSSpinLockUnlock(&spinLock);復制代碼

然而，YYKit作者的文章不再安全的 OSSpinLock有說到這個自旋鎖存在優先級反轉的問題，

7.2 os_unfair_lock

自旋鎖已經不再安全，然后蘋果又整出來個 os_unfair_lock_t ,這個鎖解決了優先級反轉的問題，

    os_unfair_lock_t unfairLock;
    unfairLock = &(OS_UNFAIR_LOCK_INIT);
    os_unfair_lock_lock(unfairLock);
    os_unfair_lock_unlock(unfairLock);復制代碼

8、atomic(property) set / get

利用set / get 介面的屬性實作原子操作，進而確保“被共享”的變數在多執行緒中讀寫安全，這已經是不能滿足部分多執行緒同步要求，

在定義 property 的時候，有atomic 和 nonatomic的屬性修飾關鍵字，
對于atomic的屬性，系統生成的 getter/setter 會保證 get、set 操作的完整性，不受其他執行緒影響，比如，執行緒 A 的 getter 方法運行到一半，執行緒 B 呼叫了 setter：那么執行緒 A 的 getter 還是能得到一個完好無損的物件，
而nonatomic就沒有這個保證了，所以，nonatomic的速度要比atomic快，

raw3d

Atomic

是默認的
會保證 CPU 能在別的執行緒來訪問這個屬性之前，先執行完當前流程
速度不快，因為要保證操作整體完成

Non-Atomic

不是默認的
更快
執行緒不安全
如有兩個執行緒訪問同一個屬性，會出現無法預料的結果

Vijayendra Tripathi

假設有一個 atomic 的屬性 “name”，如果執行緒 A 調[self setName:@"A"]，執行緒 B 調[self setName:@"B"]，執行緒 C 調`[self name]``，那么所有這些不同執行緒上的操作都將依次順序執行——也就是說，如果一個執行緒正在執行 getter/setter，其他執行緒就得等待，因此，屬性 name 是讀/寫安全的，
但是，如果有另一個執行緒 D 同時在調[name release]，那可能就會crash，因為 release 不受 getter/setter 操作的限制，也就是說，這個屬性只能說是讀/寫安全的，但并不是執行緒安全的，因為別的執行緒還能進行讀寫之外的其他操作，執行緒安全需要開發者自己來保證，
如果 name 屬性是 nonatomic 的，那么上面例子里的所有執行緒 A、B、C、D 都可以同時執行，可能導致無法預料的結果，如果是 atomic 的，那么 A、B、C 會串行，而 D 還是并行的，

簡單來說，就是atomic會加一個鎖來保障執行緒安全，并且參考計數會+1，來向呼叫者保證這個物件會一直存在，假如不這樣做，如果另一個執行緒調setter，可能會出現執行緒競態，導致參考計數降到0，原來那個物件就是否了，

9、ONCE

9.1 GCD

多用于創建單例，

+ (instancetype) sharedInstance {
    static id __instance = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        __instance = [[self alloc] init];
    });
    return __instance;
}復制代碼

9.2 pthread

廢話不多說，直接上代碼

// 定義方法
void fun() {
    NSLog(@"%@", [NSThread currentThread]);
}

- (void)onceOfPthread {
    __block pthread_once_t once = PTHREAD_ONCE_INIT;

    int i= 0;
    while (i > 5) {
        pthread_once(&once, fun);
        i++;
    }

}復制代碼

三、性能對比

基礎表現-所操作耗時

上圖是常規的鎖操作性能測驗(iOS7.0SDK，iPhone6模擬器，Yosemite 10.10.5)，垂直方向表示耗時，單位是秒，總耗時越小越好，水平方向表示不同型別鎖的鎖操作，具體又分為兩部分，左邊的常規lock操作(比如NSLock)或者讀read操作(比如ANReadWriteLock)，右邊則是寫write操作，圖上僅有ANReadWriteLock和ANRecursiveRWLock支持，其它不支持的則默認為0，圖上看出，單從性能表現，原子操作是表現最佳的(0.057412秒)，@synchronized則是最耗時的(1.753565秒) (測驗代碼) ，

多執行緒鎖洗掉陣列性能測驗

模擬器環境：i5 2.6GH+8G 記憶體，xcode 7.2.1 (7C1002)+iPhone6SP(9.2)

真機環境：xcode 7.2.1 (7C1002)+iPhone6(國行)

通過測驗發現模擬器和真機的區別還是很大的，模擬器上明顯的階梯感，真機就沒有，模擬器上NSConditionLock的性能非常差，我沒有把它的引數加在表格上，不然其他的就看不到了，不過真機上面性能還好，
這些性能測驗只是一個參考，沒必要非要去在意這些，畢竟前端的編程一般執行緒要求沒那么高，可以從其他的地方優化，執行緒安全中注意避坑，另外選擇自己喜歡的方式，這樣你可以研究的更深入，使用的更熟練，

宣告：測驗結果僅僅代表一個參考，因為各種因素的影響，并沒有那么準確，

綜合比較

可以看到除了 OSSpinLock 外，dispatch_semaphore 和 pthread_mutex 性能是最高的，有訊息稱，蘋果在新的系統中已經優化了 pthread_mutex 的性能，所有它看上去和 dispatch_semaphore 差距并沒有那么大了，

四、常見的死鎖

首先要明確幾個概念

1.串行與并行

在使用GCD的時候，我們會把需要處理的任務放到Block中，然后將任務追加到相應的佇列里面，這個佇列，叫做 Dispatch Queue，然而，存在于兩種Dispatch Queue，一種是要等待上一個任務執行完，再執行下一個的Serial Dispatch Queue，這叫做串行佇列；另一種，則是不需要上一個任務執行完，就能執行下一個的ConcurrentDispatch Queue，叫做并行佇列，這兩種，均遵循FIFO原則，

舉一個簡單的例子，在三個任務中輸出1、2、3，串行佇列輸出是有序的1、2、3，但是并行佇列的先后順序就不一定了，

雖然可以同時多個任務的處理，但是并行佇列的處理量，還是要根據當前系統狀態來，如果當前系統狀態最多處理2個任務，那么1、2會排在前面，3什么時候操作，就看1或者2誰先完成，然后3接在后面，

串行和并行就簡單說到這里，關于它們的技術點其實還有很多，可以自行了解，

2.同步與異步

串行與并行針對的是佇列，而同步與異步，針對的則是執行緒，最大的區別在于，同步執行緒要阻塞當前執行緒，必須要等待同步執行緒中的任務執行完，回傳以后，才能繼續執行下一個任務；而異步執行緒則是不用等待，

3.GCD API

GCD API很多，這里僅介紹本文用到的，

1. 系統提供的兩個佇列

// 全域佇列，也是一個并行佇列
dispatch_get_global_queue
// 主佇列，在主執行緒中運行，因為主執行緒只有一個，所有這是一個串行佇列
dispatch_get_main_queue復制代碼

1. 除此之外，還可以自己生成佇列

// 從DISPATCH_QUQUE_SERIAL看出，這是串行佇列
dispatch_queue_create("com.demo.serialQueue", DISPATCH_QUEUE_SERIAL)
// 同理，這是一個并行佇列
dispatch_queue_create("com.demo.concurrentQueue", DISPATCH_QUEUE_CONCURRENT)復制代碼

1. 接下來是同步與異步執行緒的創造

dispatch_sync(..., ^(block)) // 同步執行緒
dispatch_async(..., ^(block)) // 異步執行緒復制代碼

案例分析

案例一

NSLog(@"1"); // 任務1
dispatch_sync(dispatch_get_main_queue(), ^{
    NSLog(@"2"); // 任務2
});
NSLog(@"3"); // 任務3復制代碼

結果，控制臺輸出：

1復制代碼

分析

1. dispatch_sync表示一個同步執行緒；
1. dispatch_get_main_queue表示運行在主執行緒中的主佇列；
1. 任務2是同步執行緒的任務，

首先執行任務1，這是肯定沒問題的，只是接下來，程式遇到了同步執行緒，那么它會進入等待，等待任務2執行完，然后執行任務3，但這是佇列，有任務來，當然會將任務加到隊尾，然后遵循FIFO原則執行任務，那么，現在任務2就會被加到最后，任務3排在了任務2前面，問題來了：

任務3要等任務2執行完才能執行，任務2由排在任務3后面，意味著任務2要在任務3執行完才能執行，所以他們進入了互相等待的局面，【既然這樣，那干脆就卡在這里吧】這就是死鎖，

案例二

NSLog(@"1"); // 任務1
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
    NSLog(@"2"); // 任務2
});
NSLog(@"3"); // 任務3復制代碼

結果，控制臺輸出：

1
2
3復制代碼

分析

首先執行任務1，接下來會遇到一個同步執行緒，程式會進入等待，等待任務2執行完成以后，才能繼續執行任務3，從dispatch_get_global_queue可以看出，任務2被加入到了全域的并行佇列中，當并行佇列執行完任務2以后，回傳到主佇列，繼續執行任務3，

案例三

dispatch_queue_t queue = dispatch_queue_create("com.demo.serialQueue", DISPATCH_QUEUE_SERIAL);
NSLog(@"1"); // 任務1
dispatch_async(queue, ^{
    NSLog(@"2"); // 任務2
    dispatch_sync(queue, ^{  
        NSLog(@"3"); // 任務3
    });
    NSLog(@"4"); // 任務4
});
NSLog(@"5"); // 任務5復制代碼

結果，控制臺輸出：

1
5
2
// 5和2的順序不一定復制代碼

分析

這個案例沒有使用系統提供的串行或并行佇列，而是自己通過dispatch_queue_create函式創建了一個DISPATCH_QUEUE_SERIAL的串行佇列，

1. 執行任務1；
1. 遇到異步執行緒，將【任務2、同步執行緒、任務4】加入串行佇列中，因為是異步執行緒，所以在主執行緒中的任務5不必等待異步執行緒中的所有任務完成；
1. 因為任務5不必等待，所以2和5的輸出順序不能確定；
1. 任務2執行完以后，遇到同步執行緒，這時，將任務3加入串行佇列；
1. 又因為任務4比任務3早加入串行佇列，所以，任務3要等待任務4完成以后，才能執行，但是任務3所在的同步執行緒會阻塞，所以任務4必須等任務3執行完以后再執行，這就又陷入了無限的等待中，造成死鎖，

案例四

NSLog(@"1"); // 任務1
dispatch_async(dispatch_get_global_queue(0, 0), ^{
    NSLog(@"2"); // 任務2
    dispatch_sync(dispatch_get_main_queue(), ^{
        NSLog(@"3"); // 任務3
    });
    NSLog(@"4"); // 任務4
});
NSLog(@"5"); // 任務5復制代碼

結果，控制臺輸出：

1
2
5
3
4
// 5和2的順序不一定復制代碼

分析

首先，將【任務1、異步執行緒、任務5】加入Main Queue中，異步執行緒中的任務是：【任務2、同步執行緒、任務4】，

所以，先執行任務1，然后將異步執行緒中的任務加入到Global Queue中，因為異步執行緒，所以任務5不用等待，結果就是2和5的輸出順序不一定，

然后再看異步執行緒中的任務執行順序，任務2執行完以后，遇到同步執行緒，將同步執行緒中的任務加入到Main Queue中，這時加入的任務3在任務5的后面，

當任務3執行完以后，沒有了阻塞，程式繼續執行任務4，

從以上的分析來看，得到的幾個結果：1最先執行；2和5順序不一定；4一定在3后面，

案例五

dispatch_async(dispatch_get_global_queue(0, 0), ^{
    NSLog(@"1"); // 任務1
    dispatch_sync(dispatch_get_main_queue(), ^{
        NSLog(@"2"); // 任務2
    });
    NSLog(@"3"); // 任務3
});
NSLog(@"4"); // 任務4
while (1) {
}
NSLog(@"5"); // 任務5復制代碼

結果，控制臺輸出：

1
4
// 1和4的順序不一定復制代碼

分析

和上面幾個案例的分析類似，先來看看都有哪些任務加入了Main Queue：【異步執行緒、任務4、死回圈、任務5】，

在加入到Global Queue異步執行緒中的任務有：【任務1、同步執行緒、任務3】，

第一個就是異步執行緒，任務4不用等待，所以結果任務1和任務4順序不一定，

任務4完成后，程式進入死回圈，Main Queue阻塞，但是加入到Global Queue的異步執行緒不受影響，繼續執行任務1后面的同步執行緒，

同步執行緒中，將任務2加入到了主執行緒，并且，任務3等待任務2完成以后才能執行，這時的主執行緒，已經被死回圈阻塞了，所以任務2無法執行，當然任務3也無法執行，在死回圈后的任務5也不會執行，

最終，只能得到1和4順序不定的結果，

五、總結

1. 總的來看，推薦pthread_mutex作為實際專案的首選方案；
1. 對于耗時較大又易沖突的讀操作，可以使用讀寫鎖代替pthread_mutex；
1. 如果確認僅有set/get的訪問操作，可以選用原子操作屬性；
1. 對于性能要求苛刻，可以考慮使用OSSpinLock，需要確保加鎖片段的耗時足夠小；
1. 條件鎖基本上使用面向物件的NSCondition和NSConditionLock即可；
1. @synchronized則適用于低頻場景如初始化或者緊急修復使用；

蘋果為多執行緒、共享記憶體提供了多種同步解決方案(鎖),對于這些方案的比較，大都討論了鎖的用法以及鎖操作的開銷，個人認為最優秀的選用還是看應用場景，高頻介面VS低頻介面、有限沖突VS激烈競爭、代碼片段耗時的長短，都是選擇的重要依據，選擇適用于當前應用場景的方案才是王道，

如果有錯誤或者不足的地方請指正，

作為一個開發者，有一個學習的氛圍跟一個交流圈子特別重要，這是我的iOS交流圈:
不管你是小白還是大牛歡迎入駐！！
分享內容包括逆向安防、演算法、架構設計、多執行緒，網路進階，還有底層、音視頻、Flutter等等…
自己根據梳理網路來的的開發經驗總結的學習方法，無償分享給大家，需要的話都可以自行來獲取下載，
+裙：196800191、或者是+ WX（XiAZHiGardenia）
或者是+ WX（XiAZHiGardenia）免費獲取！獲取面試資料簡歷模板一起交流技術

作者：喵渣渣
原文鏈接：https://juejin.cn/post/6844903511147167751

參考檔案

Threading Programming Guide
不再安全的 OSSpinLock
iOS 鎖的簡單實作與總結
iOS中的各種鎖
NSRecursiveLock遞回鎖的使用
iOS GCD死鎖

關注下面的標簽，發現更多相似文章

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/233982.html

標籤：其他

上一篇：Github進不去（已解決）hosts 檔案修改不了（已解決）網址為 https___github.com_ 的網頁可能暫時無法連接，或者它已永久性地移動到了新網址。

下一篇：PriorityQueue的基本概念

iOS多執行緒的鎖,你知道多少？

前言

目錄

第一部分：什么是鎖

第二部分：鎖的分類

第三部分：性能對比

第四部分：常見的死鎖

第五部分：總結(附Demo)

正文

一、什么是鎖

二、鎖的分類

1、互斥鎖

2、遞回鎖

3、信號量

4、條件鎖

5、分布式鎖

6、讀寫鎖

7、自旋鎖

8、atomic(property) set / get

9、ONCE

三、性能對比

四、常見的死鎖

1.串行與并行

2.同步與異步

3.GCD API

案例分析

案例一

案例二

案例三

案例四

案例五

五、總結

參考檔案

iOS多執行緒的鎖,你知道多少？

前言

目錄

第一部分： 什么是鎖

第二部分： 鎖的分類

第三部分： 性能對比

第四部分： 常見的死鎖

第五部分： 總結(附Demo)

正文

一、什么是鎖

二、鎖的分類

1、互斥鎖

2、遞回鎖

3、信號量

4、條件鎖

5、分布式鎖

6、讀寫鎖

7、自旋鎖

8、atomic(property) set / get

9、ONCE

三、性能對比

四、常見的死鎖

1.串行與并行

2.同步與異步

3.GCD API

案例分析

案例一

案例二

案例三

案例四

案例五

五、總結

參考檔案

第一部分：什么是鎖

第二部分：鎖的分類

第三部分：性能對比

第四部分：常見的死鎖

第五部分：總結(附Demo)