iOS底层探索之多线程(十七)——通过 Swift的Foundation源码分析锁(NSLockNSConditionNSRecursiveLock)

Posted 卡卡西Sensei

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了iOS底层探索之多线程(十七)——通过 Swift的Foundation源码分析锁(NSLockNSConditionNSRecursiveLock)相关的知识,希望对你有一定的参考价值。

ios 开发,各种锁你了解多少?NSLock、NSCondtion、NSRecursiveLock…

回顾

上篇博客中已经对NSLockNSCondtionNSRecursiveLockNSCondition等锁进行了举例分析,那么本篇博客就继续分析锁,从Foundation源码分析锁!

iOS底层探索之多线程(一)—进程和线程

iOS底层探索之多线程(二)—线程和锁

iOS底层探索之多线程(三)—初识GCD

iOS底层探索之多线程(四)—GCD的队列

iOS底层探索之多线程(五)—GCD不同队列源码分析

iOS底层探索之多线程(六)—GCD源码分析(sync 同步函数、async 异步函数)

iOS底层探索之多线程(七)—GCD源码分析(死锁的原因)

iOS底层探索之多线程(八)—GCD源码分析(函数的同步性、异步性、单例)

iOS底层探索之多线程(九)—GCD源码分析(栅栏函数)

iOS底层探索之多线程(十)—GCD源码分析( 信号量)

iOS底层探索之多线程(十一)—GCD源码分析(调度组)

iOS底层探索之多线程(十二)—GCD源码分析(事件源)

iOS底层探索之多线程(十三)—锁的种类你知多少?

iOS底层探索之多线程(十四)—关于@synchronized锁你了解多少?

iOS底层探索之多线程(十五)—@synchronized源码分析

iOS底层探索之多线程(十六)——锁分析(NSLock、NSCondtion、NSRecursiveLock、NSCondition)

1. 从Foundation源码分析锁

上篇博客对NSLockNSCondtionNSRecursiveLock等锁的使用,进行了代码的举例和分析,那么他们其实都是对pthread锁进行了一层封装。通过查看 NSLockAPI,发现是在Foundation框架下的如图:

通过查看 API 发现,锁都是遵循了一个叫做NSLocking的协议,所以大部分锁都是有如下两个方法的:

@protocol NSLocking

- (void)lock;
- (void)unlock;

@end

但是OCFoundation框架是不开源的,那难道我们的探索就止步于此了吗?有没有其他的方式来探索呢?

有的,我们可以通过 swiftFoundation框架的开源源码来看看锁是如何封装实现的,说干就干!👉源码戳这里

  • NSLock


swiftFoundation的源码工程中搜索NSLocking协议,发现这里针对不同的平台进行了一些设置和初始化工作,很明显可以看出来是对pthread的封装。

还有构造方法(init)、析构方法(deinit)、加锁(lock)、解锁(unlock)的方法定义,如下:

  • 构造方法init()就是调用了pthreadpthread_mutex_init(mutex, nil)方法
  • 析构方法deinit就是调用了pthreadpthread_mutex_destroy(mutex)方法
  • 加锁方法 lock()就是调用了pthreadpthread_mutex_lock(mutex)方法
  • 解锁方法 unlock()就是调用了pthreadpthread_mutex_unlock(mutex)方法

通过NSLockNSRecursiveLock方法的对比,发现它们的lock()方法都是一样的,都调用了pthread_mutex_lock(mutex),如下:

  • NSRecursiveLock

那为什么NSRecursiveLock就可以支持可递归加锁呢?why ?为什么呢!请继续往下看:


NSRecursiveLock方法支持可递归加锁,原因就是图中所示,在init方法中,通过pthread_mutexattr_settype(attrs, Int32(PTHREAD_MUTEX_RECURSIVE))进行了递归的设置,这一波操作真是很细节,非常的人性化的设计,着实到位👍(ps:哈哈)

  • NSCondition


通过搜索,发现NSCondition方法也是对pthread进行了封装,就是多了个对 cond的处理,除了进行pthread_mutex互斥处理外,还对pthread_cond进行了处理,同时提供了waitsignalbroadcase等方法,如下图所示:

  • NSConditionLock


NSConditionLock方法,里面没有直接对进行pthread_mutex进行封装,只是属性里面使用了NSCondition类型的_cond属性和一个_swift_CFThreadRef类型的属性,通过这两个属性,实现加锁和线程方面的相关处理。

  • NSCondition里面是包含了对pthread_mutex的封装
  • _swift_CFThreadRef其实是等于pthread_t

2. NSLocationLock分析

先来看看下面👇的代码,猜猜打印的顺序:

NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2];
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
        [conditionLock lockWhenCondition:1];
        NSLog(@"线程 1");
        [conditionLock unlockWithCondition:0];
    });
    
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{
        [conditionLock lockWhenCondition:2];
        sleep(0.1);
        NSLog(@"线程 2");
        [conditionLock unlockWithCondition:1];
    });
    
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
       [conditionLock lock];
       NSLog(@"线程 3");
       [conditionLock unlock];
    });
  • 代码运行结果

这里线程 2 一定比线程 1先执行,因为NSConditionLock 锁,⼀旦⼀个线程获得锁,其他线程⼀定会等待,在初始化的时候设置了条件2,所以线程 2优先级高于线程 1

  • [xxxx lock]:表示 xxx期待获得锁,如果没有其他线程获得锁(不需要判断内部的condition) 那它能执⾏此⾏以下代码,如果已经有其他线程获得锁(可能是条件锁,或者⽆条件锁),则等待,直⾄其他线程解锁
  • [xxx lockWhenCondition:A条件]:表示如果没有其他线程获得该锁,但是该锁内部的condition不等于A条件,它依然不能获得锁,仍然等待。如果内部的condition等于A条件,并且没有其他线程获得该锁,则进⼊代码区,同时设置它获得该锁,其他任何线程都将等待它代码的完成,直⾄它解锁。
  • [xxx unlockWithCondition:A条件]: 表示释放锁,同时把内部的condition设置为A条件
  • return = [xxx lockWhenCondition:A条件 beforeDate:A时间]:表示如果被锁定(没获得锁),并超过该时间则不再阻塞线程。但是注意:返回的值是NO,它没有改变锁的状态,这个函数的⽬的在于可以实现两种状态下的处理
  • 所谓的condition就是整数,内部通过整数⽐较条件
  1. 线程 1 调⽤[NSConditionLock lockWhenCondition:],此时此刻因为不满⾜当前条件,所以会进⼊ waiting状态,当前进⼊到waiting时,会释放当前的互斥锁。
  2. 此时当前的线程 3 调⽤[NSConditionLock lock:],本质上是调⽤[NSConditionLock lockBeforeDate:],这⾥不需要⽐对条件值,所以线程 3会打印。
  3. 接下来线程 2 执⾏[NSConditionLock lockWhenCondition:],因为满⾜条件值,所以线程2会打印,打印完成后会调⽤[NSConditionLock unlockWithCondition:],这个时候把value设置为 1,并发送boradcast, 此时线程 1接收到当前的信号,唤醒执⾏并打印。
  4. ⾃此当前打印为 线程 3 --> 线程 2 --> 线程 1
  5. [NSConditionLock lockWhenCondition:]:这⾥会根据传⼊的 condition值和value值进⾏对⽐,如果不相等,这⾥就会阻塞,进⼊线程池,否则的话就继续代码执⾏。
  6. [NSConditionLock unlockWithCondition:]: 这⾥会先更改当前的value值,然后进⾏⼴播,唤醒当前的线程。

3.总结

  • 以上的锁,其实都是对pthread封装,你如果对pthread比较熟悉,能直接用就直接用,不能就用这些封装的就可以
  • 使用锁的时候,根据自己的业务场景来合理的使用互斥锁、递归锁、条件锁

更多内容持续更新

🌹 喜欢就点个赞吧👍🌹

🌹 觉得有收获的,可以来一波,收藏+关注,评论 + 转发,以免你下次找不到我😁🌹

🌹欢迎大家留言交流,批评指正,互相学习😁,提升自我🌹

以上是关于iOS底层探索之多线程(十七)——通过 Swift的Foundation源码分析锁(NSLockNSConditionNSRecursiveLock)的主要内容,如果未能解决你的问题,请参考以下文章

iOS底层探索之多线程(十五)—@synchronized源码分析

iOS底层探索之多线程(十四)—关于@synchronized锁你了解多少?

iOS底层探索之多线程—GCD源码分析(栅栏函数)

iOS底层探索之多线程(十三)—锁的种类你知多少?

iOS底层探索之多线程—GCD源码分析(函数的同步性异步性单例)

iOS底层探索之多线程—GCD源码分析( 信号量dispatch_semaphore_t)