寫在前面
多線程在日常開發中能起到性能優化的作用，但是一旦沒用好就會造成線程不安全，本文就來講講如何保證線程安全
一、鎖
1.線程安全
當一個線程通路資料的時候，其他的線程不能對其進行通路，直到該線程通路完畢。簡單來講就是在同一時刻，對同一個資料操作的線程隻有一個。而線程不安全，則是在同一時刻可以有多個線程對該資料進行通路，進而得不到預期的結果
即線程内操作了一個線程外的非線程安全變量，這個時候一定要考慮線程安全和同步
2.檢測安全
3.鎖的作用
鎖作為一種非強制的機制，被用來保證線程安全。每一個線程在通路資料或者資源前，要先擷取（Acquire）鎖，并在通路結束之後釋放（Release）鎖。如果鎖已經被占用，其它試圖擷取鎖的線程會等待，直到鎖重新可用
注：不要将過多的其他操作代碼放到鎖裡面，否則一個線程執行的時候另一個線程就一直在等待，就無法發揮多線程的作用了
4.鎖的分類
在iOS中鎖的基本種類隻有兩種：互斥鎖、自旋鎖，其他的比如條件鎖、遞歸鎖、信号量都是上層的封裝和實作
而在JAVA中鎖占有更大份額，有興趣可以去研究一下
5. 互斥鎖
互斥鎖(Mutual exclusion，縮寫Mutex)防止兩條線程同時對同一公共資源(比如全局變量)進行讀寫的機制。當擷取鎖操作失敗時，線程會進入睡眠，等待鎖釋放時被喚醒
互斥鎖又分為：
遞歸鎖：可重入鎖，同一個線程在鎖釋放前可再次擷取鎖，即可以遞歸調用
非遞歸鎖：不可重入，必須等鎖釋放後才能再次擷取鎖
6. 自旋鎖
自旋鎖：線程反複檢查鎖變量是否可⽤。由于線程在這⼀過程中保持執⾏，
是以是⼀種忙等待。⼀旦擷取了⾃旋鎖，線程會⼀直保持該鎖，直⾄顯式釋
放⾃旋鎖
⾃旋鎖避免了程序上下⽂的排程開銷，是以對于線程隻會阻塞很短時間的場合是有效的
7.互斥鎖和自旋鎖的差別
互斥鎖線上程擷取鎖但沒有擷取到時，線程會進入休眠狀态，等鎖被釋放時線程會被喚醒
自旋鎖的線程則會一直處于等待狀态（忙等待）不會進入休眠——是以效率高
接下來就一一來介紹iOS中用到的各種鎖
二、自旋鎖
1.OSSpinLock
自從OSSpinLock出現了安全問題之後就廢棄了。自旋鎖之是以不安全，是因為自旋鎖由于擷取鎖時，線程會一直處于忙等待狀态，造成了任務的優先級反轉
而OSSpinLock忙等的機制就可能造成高優先級一直running等待，占用CPU時間片；而低優先級任務無法搶占時間片，變成遲遲完不成，不釋放鎖的情況
2.atomic
2.1 atomic原理
在iOS探索 KVC原理及自定義中有提到自動生成的setter方法會根據修飾符不同調用不同方法，最後統一調用reallySetProperty方法，其中就有一段關于atomic修飾詞的代碼
static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
if (offset == 0) {
object_setClass(self, newValue);
return;
}
id oldValue;
id *slot = (id*) ((char*)self + offset);
if (copy) {
newValue = [newValue copyWithZone:nil];
} else if (mutableCopy) {
newValue = [newValue mutableCopyWithZone:nil];
} else {
if (*slot == newValue) return;
newValue = objc_retain(newValue);
}
if (!atomic) {
oldValue = *slot;
*slot = newValue;
} else {
spinlock_t& slotlock = PropertyLocks[slot];
slotlock.lock();
oldValue = *slot;
*slot = newValue;
slotlock.unlock();
}
objc_release(oldValue);
}
複制代碼比對一下atomic的邏輯分支：
原子性修飾的屬性進行了spinlock加鎖處理
非原子性的屬性除了沒加鎖，其他邏輯與atomic一般無二
等等，前面不是剛說OSSpinLock因為安全問題被廢棄了嗎，但是蘋果源碼怎麼還在使用呢？其實點進去就會發現用os_unfair_lock替代了OSSpinLock（iOS10之後替換）
using spinlock_t = mutex_tt<LOCKDEBUG>;
class mutex_tt : nocopy_t {
os_unfair_lock mLock;
...
}
複制代碼
同時為了哈希不沖突，還使用加鹽操作進行加鎖
getter方法亦是如此：atomic修飾的屬性進行加鎖處理
id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {
if (offset == 0) {
return object_getClass(self);
}
// Retain release world
id *slot = (id*) ((char*)self + offset);
if (!atomic) return *slot;
// Atomic retain release world
spinlock_t& slotlock = PropertyLocks[slot];
slotlock.lock();
id value = objc_retain(*slot);
slotlock.unlock();
// for performance, we (safely) issue the autorelease OUTSIDE of the spinlock.
return objc_autoreleaseReturnValue(value);
}
複制代碼2.2 atomic修飾的屬性絕對安全嗎？
atomic隻能保證setter、getter方法的線程安全，并不能保證資料安全
如上圖所示，被atomic修飾的index變量分别在兩次并發異步for循環10000次後輸出的結果并不等于20000。由此可以得出結論：
atomic保證變量在取值和指派時的線程安全
但不能保證self.index+1也是安全的
如果改成self.index=i是能保證setter方法的線程安全的
3. 讀寫鎖
讀寫鎖實際是一種特殊的自旋鎖，它把對共享資源的通路者劃分成讀者和寫者，讀者隻對共享資源進行讀通路，寫者則需要對共享資源進行寫操作。這種鎖相對于自旋鎖而言，能提高并發性，因為在多處理器系統中，它允許同時有多個讀者來通路共享資源，最大可能的讀者數為實際的CPU數
寫者是排他性的，⼀個讀寫鎖同時隻能有⼀個寫者或多個讀者（與CPU數相關），但不能同時既有讀者⼜有寫者。在讀寫鎖保持期間也是搶占失效的
如果讀寫鎖目前沒有讀者，也沒有寫者，那麼寫者可以⽴刻獲得讀寫鎖，否則它必須⾃旋在那⾥，直到沒有任何寫者或讀者。如果讀寫鎖沒有寫者，那麼讀者可以⽴即獲得該讀寫鎖，否則讀者必須⾃旋在那⾥，直到寫者釋放該讀寫鎖
// 導入頭檔案
#import <pthread.h>
// 全局聲明讀寫鎖
pthread_rwlock_t lock;
// 初始化讀寫鎖
pthread_rwlock_init(&lock, NULL);
// 讀操作-加鎖
pthread_rwlock_rdlock(&lock);
// 讀操作-嘗試加鎖
pthread_rwlock_tryrdlock(&lock);
// 寫操作-加鎖
pthread_rwlock_wrlock(&lock);
// 寫操作-嘗試加鎖
pthread_rwlock_trywrlock(&lock);
// 解鎖
pthread_rwlock_unlock(&lock);
// 釋放鎖
pthread_rwlock_destroy(&lock);
複制代碼平時很少會直接使用讀寫鎖pthread_rwlock_t，更多的是采用其他方式，例如使用栅欄函數完成讀寫鎖的需求
三、互斥鎖
1.pthread_mutex
pthread_mutex就是互斥鎖本身——當鎖被占用，而其他線程申請鎖時，不是使用忙等，而是阻塞線程并睡眠
使用如下：
// 導入頭檔案
#import <pthread.h>
// 全局聲明互斥鎖
pthread_mutex_t _lock;
// 初始化互斥鎖
pthread_mutex_init(&_lock, NULL);
// 加鎖
pthread_mutex_lock(&_lock);
// 這裡做需要線程安全操作
// ...
// 解鎖
pthread_mutex_unlock(&_lock);
// 釋放鎖
pthread_mutex_destroy(&_lock);
複制代碼YYKit的YYMemoryCach有使用到pthread_mutex
[email protected]
@synchronized可能是日常開發中用的比較多的一種互斥鎖，因為它的使用比較簡單，但并不是在任意場景下都能使用@synchronized，且它的性能較低
@synchronized (obj) {}
複制代碼接下來就通過源碼探索來看一下@synchronized在使用中的注意事項
通過彙編能發現@synchronized就是實作了objc_sync_enter和 objc_sync_exit兩個方法
通過符号斷點能知道這兩個方法都是在objc源碼中的
通過clang也能得到一些資訊：
int main(int argc, char * argv[]) {
NSString * appDelegateClassName;
/* @autoreleasepool */ { __AtAutoreleasePool __autoreleasepool;
appDelegateClassName = NSStringFromClass(((Class (*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("AppDelegate"), sel_registerName("class")));
{
id _rethrow = 0;
id _sync_obj = (id)appDelegateClassName;
objc_sync_enter(_sync_obj);
try {
struct _SYNC_EXIT {
_SYNC_EXIT(id arg) : sync_exit(arg) {}
~_SYNC_EXIT() {
objc_sync_exit(sync_exit);
}
id sync_exit;
}
_sync_exit(_sync_obj);
}
catch (id e) {_rethrow = e;}
{
struct _FIN { _FIN(id reth) : rethrow(reth) {}
~_FIN() { if (rethrow) objc_exception_throw(rethrow); }
id rethrow;
}_fin_force_rethow(_rethrow);
}
}
}
return UIApplicationMain(argc, argv, __null, appDelegateClassName);
}
複制代碼2.1 源碼分析
在objc源碼中找到objc_sync_enter和objc_sync_exit
// Begin synchronizing on 'obj'.
// Allocates recursive mutex associated with 'obj' if needed.
// Returns OBJC_SYNC_SUCCESS once lock is acquired.
int objc_sync_enter(id obj)
{
int result = OBJC_SYNC_SUCCESS;
if (obj) {
SyncData* data = id2data(obj, ACQUIRE);
assert(data);
data->mutex.lock();
} else {
// @synchronized(nil) does nothing
if (DebugNilSync) {
_objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
}
objc_sync_nil();
}
return result;
}
// End synchronizing on 'obj'.
// Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR
int objc_sync_exit(id obj)
{
int result = OBJC_SYNC_SUCCESS;
if (obj) {
SyncData* data = id2data(obj, RELEASE);
if (!data) {
result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
} else {
bool okay = data->mutex.tryUnlock();
if (!okay) {
result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
}
}
} else {
// @synchronized(nil) does nothing
}
return result;
}
複制代碼
首先從它的注釋中recursive mutex可以得出@synchronized是遞歸鎖
如果鎖的對象obj不存在時分别會走objc_sync_nil()和不做任何操作（源碼分析可以先解決簡單的邏輯分支）
BREAKPOINT_FUNCTION(
void objc_sync_nil(void)
);
複制代碼這也是@synchronized作為遞歸鎖但能防止死鎖的原因所在：在不斷遞歸的過程中如果對象不存在了就會停止遞歸進而防止死鎖
正常情況下（obj存在）會通過id2data方法生成一個SyncData對象
nextData指的是連結清單中下一個SyncData
object指的是目前加鎖的對象
threadCount表示使用該對象進行加鎖的線程數
mutex即對象所關聯的鎖
typedef struct alignas(CacheLineSize) SyncData {
struct SyncData* nextData;
DisguisedPtr<objc_object> object;
int32_t threadCount; // number of THREADS using this block
recursive_mutex_t mutex;
} SyncData;
複制代碼2.2 準備SyncData
static SyncData* id2data(id object, enum usage why)
{
spinlock_t *lockp = &LOCK_FOR_OBJ(object);
SyncData **listp = &LIST_FOR_OBJ(object);
SyncData* result = NULL;
...
}
複制代碼id2data先将傳回對象SyncData類型的result準備好，後續進行資料填充
#define LOCK_FOR_OBJ(obj) sDataLists[obj].lock
#define LIST_FOR_OBJ(obj) sDataLists[obj].data
static StripedMap<SyncList> sDataLists;
struct SyncList {
SyncData *data;
spinlock_t lock;
constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
};
複制代碼其中通過兩個宏定義去取得SyncList中的data和lock——static StripedMap<SyncList> sDataLists 可以了解成 NSArray<id> list
既然@synchronized能在任意地方（VC、View、Model等）使用，那麼底層必然維護着一張全局的表（類似于weak表）。而從SyncList和SyncData的結構可以證明系統确實在底層維護着一張哈希表，裡面存儲着SyncList結構的資料。SyncList和SyncData的關系如下圖所示：
2.3 使用快速緩存
static SyncData* id2data(id object, enum usage why)
{
...
#if SUPPORT_DIRECT_THREAD_KEYS
// Check per-thread single-entry fast cache for matching object
// 檢查每線程單項快速緩存中是否有比對的對象
bool fastCacheOccupied = NO;
SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
if (data) {
fastCacheOccupied = YES;
if (data->object == object) {
// Found a match in fast cache.
uintptr_t lockCount;
result = data;
lockCount = (uintptr_t)tls_get_direct(SYNC_COUNT_DIRECT_KEY);
if (result->threadCount <= 0 || lockCount <= 0) {
_objc_fatal("id2data fastcache is buggy");
}
switch(why) {
case ACQUIRE: {
lockCount++;
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
break;
}
case RELEASE:
lockCount--;
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
if (lockCount == 0) {
// remove from fast cache
tls_set_direct(SYNC_DATA_DIRECT_KEY, NULL);
// atomic because may collide with concurrent ACQUIRE
OSAtomicDecrement32Barrier(&result->threadCount);
}
break;
case CHECK:
// do nothing
break;
}
return result;
}
}
#endif
...
}
複制代碼這裡有個重要的知識點——TLS：TLS全稱為Thread Local Storage，在iOS中每個線程都擁有自己的TLS，負責儲存本線程的一些變量， 且TLS無需鎖保護
快速緩存的含義為：定義兩個變量SYNC_DATA_DIRECT_KEY/SYNC_COUNT_DIRECT_KEY，與tsl_get_direct/tls_set_direct配合可以從線程局部緩存中快速取得SyncCacheItem.data和SyncCacheItem.lockCount
如果在緩存中找到目前對象，就拿出目前被鎖的次數lockCount，再根據傳入參數類型(擷取、釋放、檢視)對lockCount分别進行操作
擷取資源ACQUIRE：lockCount++并根據key值存入被鎖次數
釋放資源RELEASE：lockCount++并根據key值存入被鎖次數。如果次數變為0，此時鎖也不複存在，需要從快速緩存移除并清空線程數threadCount
檢視資源check：不操作
lockCount表示被鎖的次數，意味着能多次進入，從側面表現出了遞歸性
2.4 擷取該線程下的SyncCache
這個邏輯分支是找不到确切的線程标記隻能進行所有的緩存周遊
static SyncData* id2data(id object, enum usage why)
{
...
SyncCache *cache = fetch_cache(NO);
if (cache) {
unsigned int i;
for (i = 0; i < cache->used; i++) {
SyncCacheItem *item = &cache->list[i];
if (item->data->object != object) continue;
// Found a match.
result = item->data;
if (result->threadCount <= 0 || item->lockCount <= 0) {
_objc_fatal("id2data cache is buggy");
}
switch(why) {
case ACQUIRE:
item->lockCount++;
break;
case RELEASE:
item->lockCount--;
if (item->lockCount == 0) {
// remove from per-thread cache
cache->list[i] = cache->list[--cache->used];
// atomic because may collide with concurrent ACQUIRE
OSAtomicDecrement32Barrier(&result->threadCount);
}
break;
case CHECK:
// do nothing
break;
}
return result;
}
}
...
}
複制代碼這裡介紹一下SyncCache和SyncCacheItem
typedef struct {
SyncData *data; //該緩存條目對應的SyncData
unsigned int lockCount; //該對象在該線程中被加鎖的次數
} SyncCacheItem;
typedef struct SyncCache {
unsigned int allocated; //該緩存此時對應的緩存大小
unsigned int used; //該緩存此時對應的已使用緩存大小
SyncCacheItem list[0]; //SyncCacheItem數組
} SyncCache;
複制代碼
SyncCacheItem用來記錄某個SyncData在某個線程中被加鎖的記錄，一個SyncData可以被多個SyncCacheItem持有
SyncCache用來記錄某個線程中所有SyncCacheItem，并且記錄了緩存大小以及已使用緩存大小
2.5 全局哈希表查找
快速、慢速流程都沒找到緩存就會來到這步——在系統儲存的哈希表進行鍊式查找
static SyncData* id2data(id object, enum usage why)
{
...
lockp->lock();
{
SyncData* p;
SyncData* firstUnused = NULL;
for (p = *listp; p != NULL; p = p->nextData) {
if ( p->object == object ) {
result = p;
// atomic because may collide with concurrent RELEASE
OSAtomicIncrement32Barrier(&result->threadCount);
goto done;
}
if ( (firstUnused == NULL) && (p->threadCount == 0) )
firstUnused = p;
}
// no SyncData currently associated with object
if ( (why == RELEASE) || (why == CHECK) )
goto done;
// an unused one was found, use it
if ( firstUnused != NULL ) {
result = firstUnused;
result->object = (objc_object *)object;
result->threadCount = 1;
goto done;
}
}
...
}
複制代碼
lockp->lock()并不是在底層對鎖進行了封裝，而是在查找過程前後進行了加鎖操作
for循環周遊連結清單，如果有符合的就goto done
尋找連結清單中未使用的SyncData并作标記
如果是RELEASE或CHECK直接goto done
如果第二步中有發現第一次使用的的對象就将threadCount标記為1且goto done
2.6 生成新資料并寫入緩存
static SyncData* id2data(id object, enum usage why)
{
...
posix_memalign((void **)&result, alignof(SyncData), sizeof(SyncData));
result->object = (objc_object *)object;
result->threadCount = 1;
new (&result->mutex) recursive_mutex_t(fork_unsafe_lock);
result->nextData = *listp;
*listp = result;
done:
lockp->unlock();
if (result) {
// Only new ACQUIRE should get here.
// All RELEASE and CHECK and recursive ACQUIRE are
// handled by the per-thread caches above.
if (why == RELEASE) {
// Probably some thread is incorrectly exiting
// while the object is held by another thread.
return nil;
}
if (why != ACQUIRE) _objc_fatal("id2data is buggy");
if (result->object != object) _objc_fatal("id2data is buggy");
#if SUPPORT_DIRECT_THREAD_KEYS
if (!fastCacheOccupied) {
// Save in fast thread cache
tls_set_direct(SYNC_DATA_DIRECT_KEY, result);
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)1);
} else
#endif
{
// Save in thread cache
if (!cache) cache = fetch_cache(YES);
cache->list[cache->used].data = result;
cache->list[cache->used].lockCount = 1;
cache->used++;
}
}
...
}
複制代碼
第三步情況均不滿足（即連結清單不存在——對象對于全部線程來說是第一次加鎖）就會建立SyncData并存在result裡，友善下次進行存儲
done分析：
先将前面的lock鎖解開
如果是RELEASE類型直接傳回nil
對ACQUIRE類型和對象的斷言判斷
!fastCacheOccupied分支表示支援快速緩存且快速緩存被占用了，将該SyncCacheItem資料寫入快速緩存中
否則将該SyncCacheItem存入該線程對應的SyncCache中
感謝 syx______ 提出的見解，關于 !fastCacheOccupied 可以看下評論區大佬的解釋
2.7 疑難解答
不能使用非OC對象作為加鎖條件——id2data中接收參數為id類型
多次鎖同一個對象會有什麼後果嗎——會從高速緩存中拿到data，是以隻會鎖一次對象
都說@synchronized性能低——是因為在底層增删改查消耗了大量性能
加鎖對象不能為nil，否則加鎖無效，不能保證線程安全
- (void)test {
_testArray = [NSMutableArray array];
for (int i = 0; i < 200000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
@synchronized (self.testArray) {
self.testArray = [NSMutableArray array];
}
});
}
}
複制代碼上面代碼一運作就會崩潰，原因是因為在某一瞬間testArray釋放了為nil，但哈希表中存的對象也變成了nil，導緻synchronized無效化
解決方案：
對self進行同步鎖，這個似乎太臃腫了
使用NSLock
3.NSLock
3.1 使用
NSLock是對互斥鎖的簡單封裝，使用如下：
- (void)test {
self.testArray = [NSMutableArray array];
NSLock *lock = [[NSLock alloc] init];
for (int i = 0; i < 200000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
[lock lock];
self.testArray = [NSMutableArray array];
[lock unlock];
});
}
}
複制代碼NSLock在AFNetworking的AFURLSessionManager.m中有使用到
想要了解一下NSLock的底層原理，但發現其是在未開源的Foundation源碼下面的，但但是Swift對Foundation卻開源了，可以在swift-corelibs-foundation下載下傳到源碼來一探究竟
從源碼來看就是對互斥鎖的簡單封裝
3.2 注意事項
使用互斥鎖NSLock異步并發調用block塊，block塊内部遞歸調用自己，問列印什麼？
- (void)test {
NSLock *lock = [[NSLock alloc] init];
dispatch_async(dispatch_get_global_queue(0, 0), ^{
static void (^block)(int);
block = ^(int value) {
NSLog(@"加鎖前");
[lock lock];
NSLog(@"加鎖後");
if (value > 0) {
NSLog(@"value——%d", value);
block(value - 1);
}
[lock unlock];
};
block(10);
});
}
複制代碼輸出結果并沒有按代碼表面的想法去走，而是隻列印了一次value值
加鎖前
加鎖後
value——10
加鎖前
複制代碼原因： 互斥鎖在遞歸調用時會造成堵塞，并非死鎖——這裡的問題是後面的代碼無法執行下去
第一次加完鎖之後還沒出鎖就進行遞歸調用
第二次加鎖就堵塞了線程（因為不會查詢緩存）
解決方案： 使用遞歸鎖NSRecursiveLock替換NSLock
4.NSRecursiveLock
4.1 使用
NSRecursiveLock使用和NSLock類似，如下代碼就能解決上個問題
- (void)test {
NSRecursiveLock *lock = [[NSRecursiveLock alloc] init];
dispatch_async(dispatch_get_global_queue(0, 0), ^{
static void (^block)(int);
block = ^(int value) {
[lock lock];
if (value > 0) {
NSLog(@"value——%d", value);
block(value - 1);
}
[lock unlock];
};
block(10);
});
}
複制代碼NSRecursiveLock在YYKit中YYWebImageOperation.m中有用到
4.2 注意事項
遞歸鎖在使用時需要注意死鎖問題——前後代碼互相等待便會産生死鎖
上述代碼在外層加個for循環，問輸出結果？
- (void)test {
NSRecursiveLock *lock = [[NSRecursiveLock alloc] init];
for (int i = 0; i < 10; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
static void (^block)(int);
block = ^(int value) {
[lock lock];
if (value > 0) {
NSLog(@"value——%d", value);
block(value - 1);
}
[lock unlock];
};
block(10);
});
}
}
複制代碼運作代碼會崩潰，并會提示野指針錯誤
原因： for循環在block内部對同一個對象進行了多次鎖操作，直到這個資源身上挂着N把鎖，最後大家都無法一次性解鎖——找不到解鎖的出口
即 線程1中加鎖1、同時線程2中加鎖2-> 解鎖1等待解鎖2 -> 解鎖2等待解鎖1 -> 無法結束解鎖——形成死鎖
解決： 可以采用使用緩存的@synchronized，因為它對對象進行鎖操作，會先從緩存查找是否有鎖syncData存在。如果有，直接傳回而不加鎖，保證鎖的唯一性
5.dispatch_semaphore
在GCD應用篇章已經對信号量進行過講解
6.NSCondition
NSCondition是一個條件鎖，可能平時用的不多，但與信号量相似：線程1需要等到條件1滿足才會往下走，否則就會堵塞等待，直至條件滿足
同樣的能在Swift源碼中找到關于NSCondition部分
open class NSCondition: NSObject, NSLocking {
internal var mutex = _MutexPointer.allocate(capacity: 1)
internal var cond = _ConditionVariablePointer.allocate(capacity: 1)
public override init() {
pthread_mutex_init(mutex, nil)
pthread_cond_init(cond, nil)
}
deinit {
pthread_mutex_destroy(mutex)
pthread_cond_destroy(cond)
}
open func lock() {
pthread_mutex_lock(mutex)
}
open func unlock() {
pthread_mutex_unlock(mutex)
}
open func wait() {
pthread_cond_wait(cond, mutex)
}
open func wait(until limit: Date) -> Bool {
guard var timeout = timeSpecFrom(date: limit) else {
return false
}
return pthread_cond_timedwait(cond, mutex, &timeout) == 0
}
open func signal() {
pthread_cond_signal(cond)
}
open func broadcast() {
pthread_cond_broadcast(cond) // wait signal
}
open var name: String?
}
複制代碼從上述精簡後的代碼可以得出以下幾點：
NSCondition是對mutex和cond的一種封裝（cond就是用于通路和操作特定類型資料的指針）
wait操作會阻塞線程，使其進入休眠狀态，直至逾時
signal操作是喚醒一個正在休眠等待的線程
broadcast會喚醒所有正在等待的線程
7.NSConditionLock
顧名思義，就是NSCondition + Lock
那麼和NSCondition的差別在于哪裡呢？接下來看一下NSConditionLock源碼
open class NSConditionLock : NSObject, NSLocking {
internal var _cond = NSCondition()
internal var _value: Int
internal var _thread: _swift_CFThreadRef?
public convenience override init() {
self.init(condition: 0)
}
public init(condition: Int) {
_value = condition
}
open func lock() {
let _ = lock(before: Date.distantFuture)
}
open func unlock() {
_cond.lock()
_thread = nil
_cond.broadcast()
_cond.unlock()
}
open var condition: Int {
return _value
}
open func lock(whenCondition condition: Int) {
let _ = lock(whenCondition: condition, before: Date.distantFuture)
}
open func `try`() -> Bool {
return lock(before: Date.distantPast)
}
open func tryLock(whenCondition condition: Int) -> Bool {
return lock(whenCondition: condition, before: Date.distantPast)
}
open func unlock(withCondition condition: Int) {
_cond.lock()
_thread = nil
_value = condition
_cond.broadcast()
_cond.unlock()
}
open func lock(before limit: Date) -> Bool {
_cond.lock()
while _thread != nil {
if !_cond.wait(until: limit) {
_cond.unlock()
return false
}
}
_thread = pthread_self()
_cond.unlock()
return true
}
open func lock(whenCondition condition: Int, before limit: Date) -> Bool {
_cond.lock()
while _thread != nil || _value != condition {
if !_cond.wait(until: limit) {
_cond.unlock()
return false
}
}
_thread = pthread_self()
_cond.unlock()
return true
}
open var name: String?
}
複制代碼從上述代碼可以得出以下幾點：
NSConditionLock是NSCondition加線程數的封裝
NSConditionLock可以設定鎖條件，而NSCondition隻是無腦的通知信号
8.os_unfair_lock
由于OSSpinLock自旋鎖的bug，替代方案是内部封裝了os_unfair_lock，而os_unfair_lock在加鎖時會處于休眠狀态，而不是自旋鎖的忙等狀态
9.互斥鎖性能對比
四、總結
OSSpinLock不再安全，底層用os_unfair_lock替代
atomic隻能保證setter、getter時線程安全，是以更多的使用nonatomic來修飾
讀寫鎖更多使用栅欄函數來實作
@synchronized在底層維護了一個哈希連結清單進行data的存儲，使用recursive_mutex_t進行加鎖
NSLock、NSRecursiveLock、NSCondition和NSConditionLock底層都是對pthread_mutex的封裝
NSCondition和NSConditionLock是條件鎖，當滿足某一個條件時才能進行操作，和信号量dispatch_semaphore類似
普通場景下涉及到線程安全，可以用NSLock
循環調用時用NSRecursiveLock
循環調用且有線程影響時，請注意死鎖，如果有死鎖問題請使用@synchronized
寫在後面
日常開發中若需要使用線程鎖來保證線程安全，請多考慮一下再選擇使用哪個鎖，@synchronized并不是最優的選擇。作為一名優秀的開發不但能讓App正常運作，更要讓它優質地運作、優化它的性能
參考資料
synchronized實作原理及缺陷分析
iOS底層學習 - 多線程之中的鎖
iOS開發中的11種鎖以及性能對比
![吃透MVC，馴服爛代碼 吃透MVC，馴服爛代碼[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)