iOS 底層探索： 學(xué)習(xí)大綱 OC篇

前言

• 上一篇講了@Synchronized 這個互斥遞歸鎖的底層的原理掸哑，今天來拓展一下iOS中其他鎖的一些原理笨篷，然后進(jìn)行對比分析。

一、 常見鎖的性能對比

可以看出，圖中鎖的性能從高到底依次是：
OSSpinLock(自旋鎖) ：性能最高
synchronized（互斥鎖）：性能最低

二、 鎖的分類

互斥鎖

它將代碼切片成為一個個代碼塊，使得當(dāng)一個代碼塊在運行時藤韵，其他線程不能運行他們之中的任意片段，只有等到該片段結(jié)束運行后才可以運行熊经。通過這種方式來防止多個線程同時對某一資源進(jìn)行讀寫的一種機制泽艘。常用的有：

• @synchronized
• NSLock
• pthread_mutex

自旋鎖

多線程同步的一種機制欲险，當(dāng)其檢測到資源不可用時，會保持一種“忙等”的狀態(tài)匹涮，直到獲取該資源天试。它的優(yōu)勢在于避免了上下文的切換，非常適合于堵塞時間很短的場合然低；缺點則是在“忙等”的狀態(tài)下會不停的檢測狀態(tài)喜每，會占用 cpu 資源。常用的有：

• OSSpinLock
• atomic

條件鎖

通過一些條件來控制資源的訪問雳攘，當(dāng)然條件是會發(fā)生變化的带兜。常用的有：

• NSCondition
• NSConditionLock

信號量

是一種高級的同步機制《置穑互斥鎖可以認(rèn)為是信號量取值0/1時的特例刚照，可以實現(xiàn)更加復(fù)雜的同步。常用的有：

• dispatch_semaphore

遞歸鎖

它允許同一線程多次加鎖沃于，而不會造成死鎖涩咖。遞歸鎖是特殊的互斥鎖海诲，主要是用在循環(huán)或遞歸操作中繁莹。常用的有：

• pthread_mutex(recursive)
• NSRecursiveLock

讀寫鎖

是并發(fā)控制的一種同步機制，也稱“共享-互斥鎖”特幔，也是一種特殊的自旋鎖咨演。它把對資源的訪問者分為讀者和寫者，它允許同時有多個讀者訪問資源蚯斯，但是只允許有一個寫者來訪問資源薄风。常用的有：

• pthread（rwlock）
• dispatch_barrier_async / dispatch_barrier_sync

三、常見幾種鎖的使用方法及底層原理

3.1拍嵌、atomic（原子鎖）

atomic適用于OC中屬性的修飾符遭赂，其自帶一把自旋鎖，但是這個一般基本不使用横辆，都是使用的nonatomic

我們知道setter方法會根據(jù)修飾符調(diào)用不同方法撇他，其中最后會統(tǒng)一調(diào)用reallySetProperty方法，其中就有atomic和nonatomic操作

static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
   ...
   id *slot = (id*) ((char*)self + offset);
   ...

    if (!atomic) {//未加鎖
        oldValue = *slot;
        *slot = newValue;
    } else {//加鎖
        spinlock_t& slotlock = PropertyLocks[slot];
        slotlock.lock();
        oldValue = *slot;
        *slot = newValue;        
        slotlock.unlock();
    }
    ...
}

從源碼中可以看出狈蚤，對于atomic修飾的屬性困肩，進(jìn)行了spinlock_t加鎖處理，但是OSSpinLock已經(jīng)廢棄了脆侮，這里的spinlock_t在底層是通過os_unfair_lock替代了OSSpinLock實現(xiàn)的加鎖锌畸。同時為了防止哈希沖突，還是用了加鹽操作

using spinlock_t = mutex_tt<LOCKDEBUG>;

class mutex_tt : nocopy_t {
    os_unfair_lock mLock;
    ...
}

getter方法中對atomic的處理靖避，同setter是大致相同的

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);
}

3.2潭枣、synchronized（互斥遞歸鎖）

已分析過比默，請查看iOS 底層探索：Dispatch_source & @Synchronized

3.3、NSLock

NSLock是對下層pthread_mutex的封裝卸耘，使用如下

 NSLock *lock = [[NSLock alloc] init];
[lock lock];
[lock unlock];

直接進(jìn)入NSLock定義查看退敦，其遵循了NSLocking協(xié)議，下面來探索NSLock的底層實現(xiàn)

3.3.1 NSLock 底層分析

• NSLock源碼在Foundation框架中, 由于OC的Foundation框架不開源蚣抗，所以這里參考Swift的開源框架Foundation來 分析NSLock的底層實現(xiàn)侈百，其原理與OC是大致相同的

image.png

• 通過源碼實現(xiàn)可以看出，底層是通過pthread_mutex互斥鎖實現(xiàn)的翰铡。并且在init方法中钝域，還做了一些其他操作，所以在使用NSLock時需要使用init初始化

回到前文的性能圖中锭魔，可以看出NSLock的性能僅次于 pthread_mutex（互斥鎖）例证，非常接近

3.3.2 使用弊端

請問下面block嵌套block的代碼中，會有什么問題迷捧？

for (int i= 0; i<100; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void (^testMethod)(int);
        testMethod = ^(int value){
            if (value > 0) {
              NSLog(@"current value = %d",value);
              testMethod(value - 1);
            }
        };
        testMethod(10);
    });
}  

• 在未加鎖之前织咧，其中的current=9、10有很多條漠秋，導(dǎo)致數(shù)據(jù)混亂笙蒙，主要原因是多線程導(dǎo)致的

• 如果像下面這樣加鎖，會有什么問題庆锦？

NSLock *lock = [[NSLock alloc] init];
for (int i= 0; i<100; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void (^testMethod)(int);
        testMethod = ^(int value){
            [lock lock];
            if (value > 0) {
              NSLog(@"current value = %d",value);
              testMethod(value - 1);
            }
        };
        testMethod(10);
        [lock unlock];
    });
}  

其運行結(jié)果如下

會出現(xiàn)一直等待的情況捅位，主要是因為嵌套使用的遞歸，使用NSLock（簡單的互斥鎖搂抒，如果沒有回來艇搀，會一直睡覺等待），即會存在一直加lock求晶，等不到unlock 的堵塞情況

所以焰雕，針對這種情況，可以使用以下方式解決

• 使用@synchronized

for (int i= 0; i<100; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void (^testMethod)(int);
        testMethod = ^(int value){
            @synchronized (self) {
                if (value > 0) {
                  NSLog(@"current value = %d",value);
                  testMethod(value - 1);
                }
            }
        };
        testMethod(10); 
    });
}

• 使用遞歸鎖NSRecursiveLock

NSRecursiveLock *recursiveLock = [[NSRecursiveLock alloc] init];
 for (int i= 0; i<100; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void (^testMethod)(int);
        [recursiveLock lock];
        testMethod = ^(int value){
            if (value > 0) {
              NSLog(@"current value = %d",value);
              testMethod(value - 1);
            }
            [recursiveLock unlock];
        };
        testMethod(10);
    });
}

3.4 pthread_mutex

pthread_mutex就是互斥鎖本身芳杏，當(dāng)鎖被占用矩屁，其他線程申請鎖時，不會一直忙等待蚜锨，而是阻塞線程并睡眠档插。

使用

// 導(dǎo)入頭文件
#import <pthread.h>

// 全局聲明互斥鎖
pthread_mutex_t _lock;

// 初始化互斥鎖
pthread_mutex_init(&_lock, NULL);

// 加鎖
pthread_mutex_lock(&_lock);
// 這里做需要線程安全操作
// 解鎖 
pthread_mutex_unlock(&_lock);

// 釋放鎖
pthread_mutex_destroy(&_lock);

3.5、NSRecursiveLock

• 在聲明前加鎖和調(diào)用后解鎖是正確的亚再。

  image

• 但由于它具備遞歸特性郭膛，我們在block內(nèi)部的遞歸前加鎖，當(dāng)前線程也打印正常氛悬，但是其他線程堵塞则剃。

  image

• 當(dāng)我們?nèi)サ?code>for循環(huán)耘柱，僅保持一個異步線程，在block內(nèi)部的遞歸前后分別加鎖和解鎖棍现，打印正常：

  image

這是因為NSRecursiveLock的遞歸特性调煎。內(nèi)部任務(wù)是遞歸持有的，所以不會死鎖己肮。

image

3.6士袄、NSCondition

NSCondition 是一個條件鎖，在日常開發(fā)中使用較少谎僻，與信號量有點相似：線程1需要滿足條件1才會往下走娄柳，否則會堵塞等待，知道條件滿足艘绍。經(jīng)典模型是生產(chǎn)消費者模型

NSCondition的對象實際上作為一個鎖 和 一個線程檢查器

• 鎖主要 為了當(dāng)檢測條件時保護(hù)數(shù)據(jù)源赤拒，執(zhí)行條件引發(fā)的任務(wù)

• 線程檢查器主要是根據(jù)條件決定是否繼續(xù)運行線程，即線程是否被阻塞

使用

//初始化
NSCondition *condition = [[NSCondition alloc] init]

//一般用于多線程同時訪問诱鞠、修改同一個數(shù)據(jù)源挎挖，保證在同一 時間內(nèi)數(shù)據(jù)源只被訪問、修改一次航夺，其他線程的命令需要在lock 外等待蕉朵，只到 unlock ，才可訪問
[condition lock];

//與lock 同時使用
[condition unlock];

//讓當(dāng)前線程處于等待狀態(tài)
[condition wait];

//CPU發(fā)信號告訴線程不用在等待敷存，可以繼續(xù)執(zhí)行
[condition signal];

通過swift的Foundation源碼查看NSCondition的底層實現(xiàn)

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)
    }
    //析構(gòu)
    deinit {
        pthread_mutex_destroy(mutex)
        pthread_cond_destroy(cond)

        mutex.deinitialize(count: 1)
        cond.deinitialize(count: 1)
        mutex.deallocate()
        cond.deallocate()
    }
    //加鎖
    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
    }
    //信號墓造，表示等待的可以執(zhí)行了
    open func signal() {
        pthread_cond_signal(cond)
    }
    //廣播
    open func broadcast() {
        // 匯編分析 - 猜 (多看多玩)
        pthread_cond_broadcast(cond) // wait  signal
    }
    open var name: String?
}

其底層也是對下層pthread_mutex的封裝

• NSCondition是對mutex和cond的一種封裝（cond就是用于訪問和操作特定類型數(shù)據(jù)的指針）

• wait操作會阻塞線程堪伍，使其進(jìn)入休眠狀態(tài)锚烦，直至超時

• signal操作是喚醒一個正在休眠等待的線程

• broadcast會喚醒所有正在等待的線程

3.6、NSConditionLock

NSConditionLock是條件鎖帝雇，一旦一個線程獲得鎖涮俄，其他線程一定等待

相比NSConditionLock而言，NSCondition使用比較麻煩尸闸，所以推薦使用NSConditionLock彻亲，其使用如下

//初始化
NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2];

//表示 conditionLock 期待獲得鎖，如果沒有其他線程獲得鎖(不需要判斷內(nèi)部的 condition) 那它能執(zhí)行此行以下代碼吮廉，如果已經(jīng)有其他線程獲得鎖(可能是條件鎖苞尝，或者無條件 鎖)，則等待宦芦，直至其他線程解鎖
[conditionLock lock]; 

//表示如果沒有其他線程獲得該鎖宙址，但是該鎖內(nèi)部的 condition不等于A條件，它依然不能獲得鎖调卑，仍然等待抡砂。如果內(nèi)部的condition等于A條件大咱，并且 沒有其他線程獲得該鎖，則進(jìn)入代碼區(qū)注益，同時設(shè)置它獲得該鎖碴巾，其他任何線程都將等待它代碼的 完成，直至它解鎖丑搔。
[conditionLock lockWhenCondition:A條件]; 

//表示釋放鎖厦瓢，同時把內(nèi)部的condition設(shè)置為A條件
[conditionLock unlockWithCondition:A條件]; 

// 表示如果被鎖定(沒獲得 鎖)，并超過該時間則不再阻塞線程啤月。但是注意:返回的值是NO,它沒有改變鎖的狀態(tài)旷痕，這個函 數(shù)的目的在于可以實現(xiàn)兩種狀態(tài)下的處理
return = [conditionLock lockWhenCondition:A條件 beforeDate:A時間];

//其中所謂的condition就是整數(shù)，內(nèi)部通過整數(shù)比較條件

NSConditionLock顽冶，其本質(zhì)就是NSCondition + Lock欺抗，以下是其swift的底層實現(xiàn)，

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可以設(shè)置鎖條件强重，即condition值绞呈，而NSCondition只是信號的通知

四、性能總結(jié)

• OSSpinLock自旋鎖由于安全性問題间景，在iOS10之后已經(jīng)被廢棄佃声，其底層的實現(xiàn)用os_unfair_lock替代

  • 使用OSSpinLock及所示，會處于忙等待狀態(tài)

  • 而os_unfair_lock是處于休眠狀態(tài)

• atomic原子鎖自帶一把自旋鎖倘要，只能保證setter圾亏、getter時的線程安全，在日常開發(fā)中使用更多的還是nonatomic修飾屬性

  • atomic：當(dāng)屬性在調(diào)用setter封拧、getter方法時志鹃，會加上自旋鎖osspinlock，用于保證同一時刻只能有一個線程調(diào)用屬性的讀或?qū)懀?code>避免了屬性讀寫不同步的問題泽西。由于是底層編譯器自動生成的互斥鎖代碼曹铃，會導(dǎo)致效率相對較低

  • nonatomic：當(dāng)屬性在調(diào)用setter、getter方法時捧杉，不會加上自旋鎖陕见，即線程不安全。由于編譯器不會自動生成互斥鎖代碼味抖，可以提高效率

• @synchronized在底層維護(hù)了一個哈希表進(jìn)行線程data的存儲评甜，通過鏈表表示可重入（即嵌套）的特性，雖然性能較低仔涩，但由于簡單好用忍坷，使用頻率很高

• NSLock、NSRecursiveLock底層是對pthread_mutex的封裝

• NSCondition和NSConditionLock是條件鎖，底層都是對pthread_mutex的封裝承匣，當(dāng)滿足某一個條件時才能進(jìn)行操作蓖乘，和信號量dispatch_semaphore類似

五、 鎖的使用場景

• 如果只是簡單的使用韧骗，例如涉及線程安全嘉抒，使用NSLock即可

• 如果是循環(huán)嵌套，推薦使用@synchronized袍暴，主要是因為使用遞歸鎖的性能不如使用@synchronized的性能（因為在synchronized中無論怎么重入些侍，都沒有關(guān)系，而NSRecursiveLock可能會出現(xiàn)崩潰現(xiàn)象）

• 在循環(huán)嵌套中政模，如果對遞歸鎖掌握的很好岗宣，則建議使用遞歸鎖，因為性能好

• 如果是循環(huán)嵌套淋样，并且還有多線程影響時耗式，例如有等待、死鎖現(xiàn)象時趁猴，建議使用@synchronized