五花八門的??

前言

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

目錄

第一部分： 什么是鎖

第二部分： 鎖的分類

第三部分： 性能對比

第四部分： 常見的死鎖

第五部分： 總結(附Demo)

正文

一、什么是鎖

在過去幾十年并發研究領域的出版物中，鎖總是扮演著壞人的角色，鎖背負的指控包括引起死鎖、鎖封護（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中，鎖分為互斥鎖、遞歸鎖、信號量、條件鎖、自旋鎖、讀寫鎖（一種特所的自旋鎖）、分布式鎖。

對于數據庫的鎖分類：

這里就不再詳細的介紹了，感興趣的大家可以帶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

• 2. 除此之外，還可以自己生成隊列

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

• 3. 接下來是同步與異步線程的創造

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表示一個同步線程；
• 2. dispatch_get_main_queue表示運行在主線程中的主隊列；
• 3. 任務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；
• 2. 遇到異步線程，將【任務2、同步線程、任務4】加入串行隊列中。因為是異步線程，所以在主線程中的任務5不必等待異步線程中的所有任務完成；
• 3. 因為任務5不必等待，所以2和5的輸出順序不能確定；
• 4. 任務2執行完以后，遇到同步線程，這時，將任務3加入串行隊列；
• 5. 又因為任務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作為實際項目的首選方案；
• 2. 對于耗時較大又易沖突的讀操作，可以使用讀寫鎖代替pthread_mutex；
• 3. 如果確認僅有set/get的訪問操作，可以選用原子操作屬性；
• 4. 對于性能要求苛刻，可以考慮使用OSSpinLock，需要確保加鎖片段的耗時足夠小；
• 5. 條件鎖基本上使用面向對象的NSCondition和NSConditionLock即可；
• 6. @synchronized則適用于低頻場景如初始化或者緊急修復使用；

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

最后，由于時間匆促，如果有錯誤或者不足的地方請指正，最后附上Demo所有代碼的集合,下面是我的github和博客。

聯系方式：ed_sun0129@163.com

github

blog

參考文檔

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