[iOS] 談談iOS多線程的鎖

時間 2019-11-08

標籤 ios 談談多線程欄目 iOS 简体版

原文原文鏈接

前言

iOS開發中因爲各類第三方庫的高度封裝，對鎖的使用不多，恰好以前面試中被問到的關於併發編程鎖的問題，都是隻知其一;不知其二，因而決定整理一下關於iOS中鎖的知識，爲你們查缺補漏。html

正文

1、什麼是鎖

在過去幾十年併發研究領域的出版物中，鎖老是扮演着壞人的角色，鎖揹負的指控包括引發死鎖、鎖封護（luyang注：lock convoying，多個同優先級的線程重複競爭同一把鎖，此時大量雖然被喚醒而得不到鎖的線程被迫進行調度切換，這種頻繁的調度切換至關影響系統性能）、飢餓、不公平、data races以及其餘許多併發帶來的罪孽。有趣的是，在共享內存並行軟件中真正承擔重擔的是——你猜對了——鎖。前端

在計算機科學中，鎖是一種同步機制，用於多線程環境中對資源訪問的限制。你能夠理解成它用於排除併發的一種策略。ios

if (lock == 0) {
        lock = myPID;
    }複製代碼

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

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了。github

2、鎖的分類

鎖根據不一樣的性質能夠分紅不一樣的類。面試

在WiKiPedia介紹中，通常的鎖都是建議鎖，也就四每一個任務去訪問公共資源的時候，都須要取得鎖的資訊，再根據鎖資訊來肯定是否能夠存取。若存取對應資訊，鎖的狀態會改變爲鎖定，所以其餘線程不會訪問該資源，當結束訪問時，鎖會釋放，容許其餘任務訪問。有些系統有強制鎖，若未經受權的鎖訪問鎖定的資料，在訪問時就會產生異常。數據庫

在iOS中，鎖分爲互斥鎖、遞歸鎖、信號量、條件鎖、自旋鎖、讀寫鎖（一種特所的自旋鎖）、分佈式鎖。編程

對於數據庫的鎖分類：數組

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

這裏就再也不詳細的介紹了，感興趣的你們能夠帶Wiki
查閱相關資料。xcode

一、互斥鎖

在編程中，引入對象互斥鎖的概念，來保證共享數據操做的完整性。每一個對象都對應於一個可稱爲「互斥鎖」的標記，這個標記用來保證在任一時刻，只能有一個線程訪問對象。

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：加鎖複製代碼

二、遞歸鎖

同一個線程能夠屢次加鎖，不會形成死鎖

舉個🌰：

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複製代碼

三、信號量

信號量(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：加鎖");
    });複製代碼

四、條件鎖

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.1 NSDistributedLock

處理多個進程或多個程序之間互斥問題。
一個獲取鎖的進程或程序在是否鎖以前掛掉，鎖不會被釋放，能夠經過breakLock方式解鎖。
iOS不多用到，暫不詳細研究。

六、讀寫鎖

讀寫鎖實際是一種特殊的自旋鎖，它把對共享資源的訪問者劃分紅讀者和寫者，讀者只對共享資源進行讀訪問，寫者則須要對共享資源進行寫操做。這種鎖相對於自旋鎖而言，能提升併發性，由於在多處理器系統中，它容許同時有多個讀者來訪問共享資源，最大可能的讀者數爲實際的邏輯CPU數。寫者是排他性的，一個讀寫鎖同時只能有一個寫者或多個讀者（與CPU數相關），但不能同時既有讀者又有寫者。

6.1 dispatch_barrier_async / dispatch_barrier_sync

先來一個需求：假設咱們原先有6個任務要執行，咱們如今要插入一個任務0，這個任務0要在一、二、4都併發執行完以後才能執行，而四、五、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");
    });
}複製代碼

共同點：一、等待在它前面插入隊列的任務先執行完；二、等待他們本身的任務執行完再執行後面的任務。
不一樣點：一、dispatch_barrier_sync將本身的任務插入到隊列的時候，須要等待本身的任務結束以後纔會繼續插入被寫在它後面的任務，而後執行它們；二、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.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);複製代碼

八、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，原來那個對象就是否了。

九、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++;
    }

}複製代碼

3、性能對比

基礎表現-所操做耗時

上圖是常規的鎖操做性能測試(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 差距並無那麼大了。

4、常見的死鎖

首先要明確幾個概念

1.串行與並行

在使用GCD的時候，咱們會把須要處理的任務放到Block中，而後將任務追加到相應的隊列裏面，這個隊列，叫作 Dispatch Queue。然而，存在於兩種Dispatch Queue，一種是要等待上一個任務執行完，再執行下一個的Serial Dispatch Queue，這叫作串行隊列；另外一種，則是不須要上一個任務執行完，就能執行下一個的ConcurrentDispatch Queue，叫作並行隊列。這兩種，均遵循FIFO原則。

舉一個簡單的例子，在三個任務中輸出一、二、3，串行隊列輸出是有序的一、二、3，可是並行隊列的前後順序就不必定了。

雖然能夠同時多個任務的處理，可是並行隊列的處理量，仍是要根據當前系統狀態來。若是當前系統狀態最多處理2個任務，那麼一、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. 遇到異步線程，將【任務二、同步線程、任務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的順序不必定複製代碼

分析

首先，將【任務一、異步線程、任務5】加入Main Queue中，異步線程中的任務是：【任務二、同步線程、任務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：【異步線程、任務四、死循環、任務5】。

在加入到Global Queue異步線程中的任務有：【任務一、同步線程、任務3】。

第一個就是異步線程，任務4不用等待，因此結果任務1和任務4順序不必定。

任務4完成後，程序進入死循環，Main Queue阻塞。可是加入到Global Queue的異步線程不受影響，繼續執行任務1後面的同步線程。

同步線程中，將任務2加入到了主線程，而且，任務3等待任務2完成之後才能執行。這時的主線程，已經被死循環阻塞了。因此任務2沒法執行，固然任務3也沒法執行，在死循環後的任務5也不會執行。

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

5、總結

1. 總的來看，推薦pthread_mutex做爲實際項目的首選方案；
1. 對於耗時較大又易衝突的讀操做，可使用讀寫鎖代替pthread_mutex；
1. 若是確認僅有set/get的訪問操做，能夠選用原子操做屬性；
1. 對於性能要求苛刻，能夠考慮使用OSSpinLock，須要確保加鎖片斷的耗時足夠小；
1. 條件鎖基本上使用面向對象的NSCondition和NSConditionLock便可；
1. @synchronized則適用於低頻場景如初始化或者緊急修復使用；

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

最後，因爲時間匆促，若是有錯誤或者不足的地方請指正，最後附上Demo全部代碼的集合,下面是個人github和博客。

聯繫方式：ed_sun0129@163.com

github

blog

參考文檔

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。

[iOS] 談談iOS多線程的鎖

前言

目錄

第一部分：什麼是鎖

第二部分：鎖的分類

第三部分：性能對比

第四部分：常見的死鎖

第五部分：總結(附Demo)

正文

1、什麼是鎖

2、鎖的分類

一、互斥鎖

二、遞歸鎖

三、信號量

四、條件鎖

五、分佈式鎖

六、讀寫鎖

七、自旋鎖

八、atomic(property) set / get

九、ONCE

3、性能對比

4、常見的死鎖

1.串行與並行

2.同步與異步

3.GCD API

案例分析

案例一

案例二

案例三

案例四

案例五

5、總結

參考文檔

[iOS] 談談iOS多線程的鎖

前言

目錄

第一部分： 什麼是鎖

第二部分： 鎖的分類

第三部分： 性能對比

第四部分： 常見的死鎖

第五部分： 總結(附Demo)

正文

1、什麼是鎖

2、鎖的分類

一、互斥鎖

二、遞歸鎖

三、信號量

四、條件鎖

五、分佈式鎖

六、讀寫鎖

七、自旋鎖

八、atomic(property) set / get

九、ONCE

3、性能對比

4、常見的死鎖

1.串行與並行

2.同步與異步

3.GCD API

案例分析

案例一

案例二

案例三

案例四

案例五

5、總結

參考文檔

第一部分：什麼是鎖

第二部分：鎖的分類

第三部分：性能對比

第四部分：常見的死鎖

第五部分：總結(附Demo)