前言
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中，鎖分為互斥鎖、遞迴鎖、訊號量、條件鎖、自旋鎖、讀寫鎖（一種特所的自旋鎖）、分散式鎖。
對於資料庫的鎖分類：
| 分類方式 | 分類 |
|---|---|
| 按鎖的粒度劃分 | 表級鎖、行級鎖、頁級鎖 |
| 按鎖的級別劃分 | 共享鎖、排他鎖 |
| 按加鎖的方式劃分 | 自動鎖、顯示鎖 |
| 按鎖的使用方式劃分 | 樂觀鎖、悲觀鎖 |
| 按操作劃分 | 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快。
Atomic
- 是預設的
- 會保證 CPU 能在別的執行緒來訪問這個屬性之前，先執行完當前流程
- 速度不快，因為要保證操作整體完成
Non-Atomic
- 不是預設的
- 更快
- 執行緒不安全
- 如有兩個執行緒訪問同一個屬性，會出現無法預料的結果
-
- 假設有一個 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很多，這裡僅介紹本文用到的。
- 系統提供的兩個佇列
// 全域性佇列，也是一個並行佇列
dispatch_get_global_queue
// 主佇列，在主執行緒中執行，因為主執行緒只有一個，所有這是一個序列佇列
dispatch_get_main_queue複製程式碼- 除此之外，還可以自己生成佇列
// 從DISPATCH_QUQUE_SERIAL看出，這是序列佇列
dispatch_queue_create("com.demo.serialQueue", DISPATCH_QUEUE_SERIAL)
// 同理，這是一個並行佇列
dispatch_queue_create("com.demo.concurrentQueue", DISPATCH_QUEUE_CONCURRENT)複製程式碼- 接下來是同步與非同步執行緒的創造
dispatch_sync(..., ^(block)) // 同步執行緒
dispatch_async(..., ^(block)) // 非同步執行緒複製程式碼案例分析
案例一
NSLog(@"1"); // 任務1
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"2"); // 任務2
});
NSLog(@"3"); // 任務3複製程式碼- 結果，控制檯輸出：
1複製程式碼分析
- dispatch_sync表示一個同步執行緒；
- dispatch_get_main_queue表示執行在主執行緒中的主佇列；
- 任務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；
- 遇到非同步執行緒，將【任務2、同步執行緒、任務4】加入序列佇列中。因為是非同步執行緒，所以在主執行緒中的任務5不必等待非同步執行緒中的所有任務完成；
- 因為任務5不必等待，所以2和5的輸出順序不能確定；
- 任務2執行完以後，遇到同步執行緒，這時，將任務3加入序列佇列；
- 又因為任務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順序不定的結果。
五、總結
- 總的來看，推薦pthread_mutex作為實際專案的首選方案；
- 對於耗時較大又易衝突的讀操作，可以使用讀寫鎖代替pthread_mutex；
- 如果確認僅有set/get的訪問操作，可以選用原子操作屬性；
- 對於效能要求苛刻，可以考慮使用OSSpinLock，需要確保加鎖片段的耗時足夠小；
- 條件鎖基本上使用物件導向的NSCondition和NSConditionLock即可；
- @synchronized則適用於低頻場景如初始化或者緊急修復使用；
蘋果為多執行緒、共享記憶體提供了多種同步解決方案(鎖),對於這些方案的比較，大都討論了鎖的用法以及鎖操作的開銷。個人認為最優秀的選用還是看應用場景，高頻介面VS低頻介面、有限衝突VS激烈競爭、程式碼片段耗時的長短，都是選擇的重要依據，選擇適用於當前應用場景的方案才是王道。
最後，由於時間匆促，如果有錯誤或者不足的地方請指正，最後附上Demo所有程式碼的集合,下面是我的github和部落格。
聯絡方式：ed_sun0129@163.com