寫在前面
多線程在日常開發中能起到性能優化的作用,但是一旦沒用好就會造成線程不安全,本文就來講講如何保證線程安全
一、鎖
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
2.@synchronized
@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正常運行,更要讓它優質地運行、優化它的性能
iOS探索 細數iOS中的那些鎖
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.