iOS探索 細數iOS中的那些鎖
歡迎閱讀iOS探索系列（按序閱讀食用效果更加）c++
- iOS探索 alloc流程
- iOS探索 內存對齊&malloc源碼
- iOS探索 isa初始化&指向分析
- iOS探索 類的結構分析
- iOS探索 cache_t分析
- iOS探索 方法的本質和方法查找流程
- iOS探索 動態方法解析和消息轉發機制
- iOS探索 淺嘗輒止dyld加載流程
- iOS探索 類的加載過程
- iOS探索 分類、類拓展的加載過程
- iOS探索 isa面試題分析
- iOS探索 runtime面試題分析
- iOS探索 KVC原理及自定義
- iOS探索 KVO原理及自定義
- iOS探索 多線程原理
- iOS探索 多線程之GCD應用
- iOS探索 多線程之GCD底層分析
- iOS探索 多線程之NSOperation
- iOS探索 多線程面試題分析
- iOS探索 細數iOS中的那些鎖
寫在前面
多線程在平常開發中能起到性能優化的做用，可是一旦沒用好就會形成線程不安全，本文就來說講如何保證線程安全git
1、鎖
1.線程安全
當一個線程訪問數據的時候，其餘的線程不能對其進行訪問，直到該線程訪問完畢。簡單來說就是在同一時刻，對同一個數據操做的線程只有一個。而線程不安全，則是在同一時刻能夠有多個線程對該數據進行訪問，從而得不到預期的結果github
即線程內操做了一個線程外的非線程安全變量，這個時候必定要考慮線程安全和同步面試
2.檢測安全
3.鎖的做用
鎖做爲一種非強制的機制，被用來保證線程安全。每個線程在訪問數據或者資源前，要先獲取（Acquire）鎖，並在訪問結束以後釋放（Release）鎖。若是鎖已經被佔用，其它試圖獲取鎖的線程會等待，直到鎖從新可用swift
注：不要將過多的其餘操做代碼放到鎖裏面，不然一個線程執行的時候另外一個線程就一直在等待，就沒法發揮多線程的做用了數組
4.鎖的分類
在iOS中鎖的基本種類只有兩種：互斥鎖、自旋鎖，其餘的好比條件鎖、遞歸鎖、信號量都是上層的封裝和實現緩存
而在JAVA中鎖佔有更大份額，有興趣能夠去研究一下安全
5. 互斥鎖
互斥鎖(Mutual exclusion，縮寫Mutex)防止兩條線程同時對同一公共資源(好比全局變量)進行讀寫的機制。當獲取鎖操做失敗時，線程會進入睡眠，等待鎖釋放時被喚醒性能優化
互斥鎖又分爲：bash
遞歸鎖：可重入鎖，同一個線程在鎖釋放前可再次獲取鎖，便可以遞歸調用非遞歸鎖：不可重入，必須等鎖釋放後才能再次獲取鎖
6. 自旋鎖
自旋鎖：線程反覆檢查鎖變量是否可⽤。因爲線程在這⼀過程當中保持執⾏， 所以是⼀種忙等待。⼀旦獲取了⾃旋鎖，線程會⼀直保持該鎖，直⾄顯式釋 放⾃旋鎖
⾃旋鎖避免了進程上下⽂的調度開銷，所以對於線程只會阻塞很短期的場合是有效的
7.互斥鎖和自旋鎖的區別
互斥鎖在線程獲取鎖但沒有獲取到時，線程會進入休眠狀態，等鎖被釋放時線程會被喚醒自旋鎖的線程則會一直處於等待狀態（忙等待）不會進入休眠——所以效率高
接下來就一一來介紹iOS中用到的各類鎖
2、自旋鎖
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，更多的是採用其餘方式，例如使用柵欄函數完成讀寫鎖的需求
3、互斥鎖
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指的是鏈表中下一個SyncDataobject指的是當前加鎖的對象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);
});
}
}
複製代碼
運行代碼會崩潰，並會提示野指針錯誤
即 線程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.互斥鎖性能對比
4、總結
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正常運行，更要讓它優質地運行、優化它的性能
參考資料
相關文章
- 1. iOS進階-細數iOS中的鎖
- 2. iOS: 線程中那些常見的鎖
- 3. iOS intrinsicContentSize的探索
- 4. 探索iOS中Block的實現
- 5. 探索iOS中Block的實現原理
- 6. iOS--Runtime的那些事
- 7. IOS #ifdef 的那些事兒
- 8. iOS開發的那些坑
- 9. iOS CollectionView 的那些事
- 10. iOS中符號的那些事兒
- 更多相關文章...
- • 探索Redis事務回滾 - Redis教程
- • Spring中Bean的作用域 - Spring教程
- • 漫談MySQL的鎖機制
- • C# 中 foreach 遍歷的用法
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. Appium入門
- 2. Spring WebFlux 源碼分析(2)-Netty 服務器啓動服務流程 --TBD
- 3. wxpython入門第六步（高級組件）
- 4. CentOS7.5安裝SVN和可視化管理工具iF.SVNAdmin
- 5. jedis 3.0.1中JedisPoolConfig對象缺少setMaxIdle、setMaxWaitMillis等方法，問題記錄
- 6. 一步一圖一代碼，一定要讓你真正徹底明白紅黑樹
- 7. 2018-04-12—（重點）源碼角度分析Handler運行原理
- 8. Spring AOP源碼詳細解析
- 9. Spring Cloud（1）
- 10. python簡單爬去油價信息發送到公衆號
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. iOS進階-細數iOS中的鎖
- 2. iOS: 線程中那些常見的鎖
- 3. iOS intrinsicContentSize的探索
- 4. 探索iOS中Block的實現
- 5. 探索iOS中Block的實現原理
- 6. iOS--Runtime的那些事
- 7. IOS #ifdef 的那些事兒
- 8. iOS開發的那些坑
- 9. iOS CollectionView 的那些事
- 10. iOS中符號的那些事兒