iOS探索細數iOS中的那些鎖

歡迎閱讀iOS探索系列（按序閱讀食用效果更加）

iOS探索 alloc流程

iOS探索內存對齊&malloc源碼

iOS探索 isa初始化&指向分析

iOS探索類的結構分析

iOS探索 cache_t分析

iOS探索方法的本質和方法查找流程

iOS探索動態(tài)方法解析和消息轉發(fā)機制

iOS探索淺嘗輒止dyld加載流程

iOS探索類的加載過程

iOS探索分類迫皱、類拓展的加載過程

iOS探索 isa面試題分析

iOS探索 runtime面試題分析

iOS探索 KVC原理及自定義

iOS探索 KVO原理及自定義

iOS探索多線程原理

iOS探索多線程之GCD應用

iOS探索多線程之GCD底層分析

iOS探索多線程之NSOperation

iOS探索多線程面試題分析

iOS探索細數iOS中的那些鎖

寫在前面

多線程在日常開發(fā)中能起到性能優(yōu)化的作用，但是一旦沒用好就會造成線程不安全辖众，本文就來講講如何保證線程安全

一卓起、鎖

1.線程安全

當一個線程訪問數據的時候，其他的線程不能對其進行訪問凹炸，直到該線程訪問完畢戏阅。簡單來講就是在同一時刻，對同一個數據操作的線程只有一個啤它。而線程不安全饲握，則是在同一時刻可以有多個線程對該數據進行訪問，從而得不到預期的結果

作為一個開發(fā)者蚕键，有一個學習的氛圍跟一個交流圈子特別重要救欧，這是一個我的iOS交流群：1001906160 ，密碼‘000‘’提供一個更大的平臺,不管你是小白還是大牛歡迎入駐锣光，分享BAT,阿里面試題笆怠、面試經驗，討論技術誊爹，大家一起交流學習成長蹬刷！

即線程內操作了一個線程外的非線程安全變量瓢捉，這個時候一定要考慮線程安全和同步

2.檢測安全

image.png

3.鎖的作用

鎖作為一種非強制的機制，被用來保證線程安全办成。每一個線程在訪問數據或者資源前泡态，要先獲取（Acquire）鎖迂卢，并在訪問結束之后釋放（Release）鎖某弦。如果鎖已經被占用，其它試圖獲取鎖的線程會等待而克，直到鎖重新可用

注：不要將過多的其他操作代碼放到鎖里面靶壮，否則一個線程執(zhí)行的時候另一個線程就一直在等待，就無法發(fā)揮多線程的作用了

4.鎖的分類

在iOS中鎖的基本種類只有兩種：互斥鎖员萍、自旋鎖腾降，其他的比如條件鎖、遞歸鎖、信號量都是上層的封裝和實現

而在JAVA中鎖占有更大份額，有興趣可以去研究一下

5. 互斥鎖

互斥鎖(Mutual exclusion设捐，縮寫Mutex)防止兩條線程同時對同一公共資源(比如全局變量)進行讀寫的機制芳室。當獲取鎖操作失敗時，線程會進入睡眠，等待鎖釋放時被喚醒

互斥鎖又分為：

遞歸鎖：可重入鎖，同一個線程在鎖釋放前可再次獲取鎖，即可以遞歸調用
非遞歸鎖：不可重入蚁滋，必須等鎖釋放后才能再次獲取鎖

6. 自旋鎖

自旋鎖：線程反復檢查鎖變量是否可?。由于線程在這?過程中保持執(zhí)?赘淮，因此是?種忙等待辕录。?旦獲取了?旋鎖，線程會?直保持該鎖梢卸，直?顯式釋放?旋鎖

?旋鎖避免了進程上下?的調度開銷走诞，因此對于線程只會阻塞很短時間的場合是有效的

7.互斥鎖和自旋鎖的區(qū)別

互斥鎖在線程獲取鎖但沒有獲取到時，線程會進入休眠狀態(tài)蛤高，等鎖被釋放時線程會被喚醒
自旋鎖的線程則會一直處于等待狀態(tài)（忙等待）不會進入休眠——因此效率高

接下來就一一來介紹iOS中用到的各種鎖

二蚣旱、自旋鎖

1.OSSpinLock

自從OSSpinLock出現了安全問題之后就廢棄了。自旋鎖之所以不安全戴陡，是因為自旋鎖由于獲取鎖時塞绿，線程會一直處于忙等待狀態(tài)，造成了任務的優(yōu)先級反轉

而OSSpinLock忙等的機制就可能造成高優(yōu)先級一直running等待恤批，占用CPU時間片异吻；而低優(yōu)先級任務無法搶占時間片，變成遲遲完不成，不釋放鎖的情況

2.atomic

2.1 atomic原理

在iOS探索 KVC原理及自定義中有提到自動生成的setter方法會根據修飾符不同調用不同方法诀浪，最后統(tǒng)一調用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因為安全問題被廢棄了嗎睛竣，但是蘋果源碼怎么還在使用呢？其實點進去就會發(fā)現用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方法的線程安全月帝，并不能保證數據安全

image.png

如上圖所示，被atomic修飾的index變量分別在兩次并發(fā)異步for循環(huán)10000次后輸出的結果并不等于20000幽污。由此可以得出結論：

atomic保證變量在取值和賦值時的線程安全
但不能保證self.index+1也是安全的
如果改成self.index=i是能保證setter方法的線程安全的

3. 讀寫鎖

讀寫鎖實際是一種特殊的自旋鎖嚷辅，它把對共享資源的訪問者劃分成讀者和寫者，讀者只對共享資源進行讀訪問距误，寫者則需要對共享資源進行寫操作簸搞。這種鎖相對于自旋鎖而言，能提高并發(fā)性准潭，因為在多處理器系統(tǒng)中趁俊，它允許同時有多個讀者來訪問共享資源，最大可能的讀者數為實際的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可能是日常開發(fā)中用的比較多的一種互斥鎖，因為它的使用比較簡單兜叨，但并不是在任意場景下都能使用@synchronized穿扳，且它的性能較低

@synchronized (obj) {}
復制代碼

接下來就通過源碼探索來看一下@synchronized在使用中的注意事項

通過匯編能發(fā)現@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即對象所關聯(lián)的鎖

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準備好衩侥，后續(xù)進行數據填充

#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的結構可以證實系統(tǒng)確實在底層維護著一張哈希表履羞，里面存儲著SyncList結構的數據峦萎。SyncList和SyncData的關系如下圖所示：

image.png

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值存入被鎖次數唇聘。如果次數變?yōu)?，此時鎖也不復存在柱搜，需要從快速緩存移除并清空線程數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 全局哈希表查找

快速、慢速流程都沒找到緩存就會來到這步——在系統(tǒng)保存的哈希表進行鏈式查找

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循環(huán)遍歷鏈表匈庭，如果有符合的就goto done
- 尋找鏈表中未使用的SyncData并作標記
如果是RELEASE或CHECK直接goto done
如果第二步中有發(fā)現第一次使用的的對象就將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++;
        }
    }
    ...
}
復制代碼

第三步情況均不滿足（即鏈表不存在——對象對于全部線程來說是第一次加鎖）就會創(chuàng)建SyncData并存在result里，方便下次進行存儲
done分析：
- 先將前面的lock鎖解開
- 如果是RELEASE類型直接返回nil
- 對ACQUIRE類型和對象的斷言判斷
- !fastCacheOccupied分支表示支持快速緩存且快速緩存被占用了浑劳，將該SyncCacheItem數據寫入快速緩存中
- 否則將該SyncCacheItem存入該線程對應的SyncCache中

感謝 syx______ 提出的見解阱持，關于 !fastCacheOccupied 可以看下評論區(qū)大佬的解釋

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的底層原理鼎姊，但發(fā)現其是在未開源的Foundation源碼下面的，但但是Swift對Foundation卻開源了，可以在swift-corelibs-foundation下載到源碼來一探究竟

image.png

從源碼來看就是對互斥鎖的簡單封裝

3.2 注意事項

使用互斥鎖NSLock異步并發(fā)調用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
加鎖前
復制代碼

原因： 互斥鎖在遞歸調用時會造成堵塞婆赠，并非死鎖——這里的問題是后面的代碼無法執(zhí)行下去

第一次加完鎖之后還沒出鎖就進行遞歸調用
第二次加鎖就堵塞了線程（因為不會查詢緩存）

解決方案： 使用遞歸鎖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循環(huán)佳励，問輸出結果休里？

- (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);
        });
    }
}
復制代碼

運行代碼會崩潰，并會提示野指針錯誤

image.png

原因： for循環(huán)在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操作會阻塞線程呕缭，使其進入休眠狀態(tài)，直至超時
signal操作是喚醒一個正在休眠等待的線程
broadcast會喚醒所有正在等待的線程

7.NSConditionLock

顧名思義修己，就是NSCondition + Lock

那么和NSCondition的區(qū)別在于哪里呢恢总？接下來看一下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在加鎖時會處于休眠狀態(tài)，而不是自旋鎖的忙等狀態(tài)

9.互斥鎖性能對比

image.png

四尤辱、總結

OSSpinLock不再安全砂豌，底層用os_unfair_lock替代
atomic只能保證setter、getter時線程安全光督，所以更多的使用nonatomic來修飾
讀寫鎖更多使用柵欄函數來實現
@synchronized在底層維護了一個哈希鏈表進行data的存儲阳距，使用recursive_mutex_t進行加鎖
NSLock、NSRecursiveLock结借、NSCondition和NSConditionLock底層都是對pthread_mutex的封裝
NSCondition和NSConditionLock是條件鎖筐摘，當滿足某一個條件時才能進行操作，和信號量dispatch_semaphore類似
普通場景下涉及到線程安全，可以用NSLock
循環(huán)調用時用NSRecursiveLock
循環(huán)調用且有線程影響時咖熟，請注意死鎖圃酵，如果有死鎖問題請使用@synchronized

寫在后面

日常開發(fā)中若需要使用線程鎖來保證線程安全，請多考慮一下再選擇使用哪個鎖球恤，@synchronized并不是最優(yōu)的選擇辜昵。作為一名優(yōu)秀的開發(fā)不但能讓App正常運行，更要讓它優(yōu)質地運行咽斧、優(yōu)化它的性能

作者：我是好寶寶
鏈接：https://juejin.im/post/5ec9f3ec6fb9a047f0125fd2

iOS探索 細數iOS中的那些鎖

寫在前面

一卓起、鎖

1.線程安全

2.檢測安全

3.鎖的作用

4.鎖的分類

5. 互斥鎖

6. 自旋鎖

7.互斥鎖和自旋鎖的區(qū)別

二蚣旱、自旋鎖

1.OSSpinLock

2.atomic

2.1 atomic原理

2.2 atomic修飾的屬性絕對安全嗎射沟？

3. 讀寫鎖

三虱疏、互斥鎖

1.pthread_mutex

2.@synchronized

2.1 源碼分析

2.2 準備SyncData

2.3 使用快速緩存

2.4 獲取該線程下的SyncCache

2.5 全局哈希表查找

2.6 生成新數據并寫入緩存

2.7 疑難解答

3.NSLock

3.1 使用

3.2 注意事項

4.NSRecursiveLock

4.1 使用

4.2 注意事項

5.dispatch_semaphore

6.NSCondition

7.NSConditionLock

8.os_unfair_lock

9.互斥鎖性能對比

四尤辱、總結

寫在后面

iOS探索細數iOS中的那些鎖