美文网首页iOS
iOS底层探索之多线程(十四)—关于@synchronized锁

iOS底层探索之多线程(十四)—关于@synchronized锁

作者: 俊而不逊 | 来源:发表于2021-08-24 13:54 被阅读0次

    对于多线程你了解多少?对于锁你又了解多少?锁的原理你又知道吗?

    @synchronized

    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 开发中遇到的各种锁,也对各种锁的性能做了一个测试,的性能最好的前三名是:OSSpinLock(自旋锁) -> dispatch_semaphone(信号量) -> pthread_mutex(互斥锁) ,最差的是synchronized(互斥锁),但也是我们最常用的锁之一。那么本篇博客将针对synchronized进行分析!

    1. @synchronized举例

    还是拿售票来举例,模拟多窗口售票情况。

    // 模拟多窗口售票
    self.ticketCount = 20;//一共有 20 张车票,分为 4 个窗口售卖
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
            for (int i = 0; i < 5; i++) {
                [self saleTicket];
            }
        });
        
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            for (int i = 0; i < 5; i++) {
                [self saleTicket];
            }
        });
        
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            for (int i = 0; i < 3; i++) {
                [self saleTicket];
            }
        });
        
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            for (int i = 0; i < 10; i++) {
                [self saleTicket];
            }
        });
        
    // 售票方法
    - (void)saleTicket{
       
        if (self.ticketCount > 0) {
            self.ticketCount--;
            sleep(0.1);
            NSLog(@"当前余票还剩:%lu张",(unsigned long)self.ticketCount);
        }else{
            NSLog(@"当前车票已售罄");
        }
    
    }
    
    • 打印结果(未加锁时)
      未加锁时打印结果
      从上图中运行打印的结果来看,4 个窗口异步操作售票,出现了数据不安全的问题,打印的剩余票数的数据出现了混乱。那么通常我们会通过加锁的方式来保证在任一时刻,只能有一个线程访问该对象,以保证数据的安全和完整性。

    现在去加锁@synchronized,看看售票情况如何?

     @synchronized (self) {
             
             if (self.ticketCount > 0) {
                  self.ticketCount--;
                  sleep(0.1);
                  NSLog(@"当前余票还剩:%lu张",(unsigned long)self.ticketCount);
             }else{
                  NSLog(@"当前车票已售罄");
             }
        }
    
    • 加锁后的打印结果
      加锁后的打印结果
      -加了@synchronized互斥锁之后的打印结果非常的完整,没有出现数据的混乱现象
    • 那么为什么加了一把@synchronized锁之后,数据就安全了呢?为什么传入的参数是 self呢?传入 nil 行不行呢?
    • @synchronized是我们平时用的最多,也是用着最方便,其可读性也更高,那么带着这些问题,开启今天的探索之旅吧!

    2. @synchronized分析

    • 底层 cpp文件查看

    main.m 里面写入下面这行代码

    main.m

    使用xcrun -sdk iphoneos clang -arch arm64 -rewrite-objc main.m -o main.cpp 命令生成.cpp文件看看底层是什么样子的,如下

    main.cpp
    可以看到,调用了objc_sync_enter方法,并且使用了try-catch,在正常处理流程中,提供了_SYNC_EXIT结构体,最后也会调用对应的析构函数objc_sync_exit。这里最重要的其实就是如下两个方法
    • objc_sync_enter

    • objc_sync_exit

    • 下符号断点查看

      符号断点objc_sync_enter
      从上面图中运行结果来看,断点走了下的符号断点objc_sync_enter处, objc_sync_exit的符号断点也走了,如下图:
      符号断点objc_sync_exit

    通过下符号断点,可以知道和底层.cpp文件中的结果是一样的,都是有 objc_sync_enterobjc_sync_exit方法,也可以很容易定位到源码是在libobjc.A.dylib中。

    • 汇编查看


      汇编查看

    通过汇编我们可以发现底层调用了两个方法分别是objc_sync_enterobjc_sync_exit,通过字面可以理解,分别是进入退出。这与.cpp中看到的、还有下符号断点验证的结果是一样的。

    3. 源码分析

    通过上面的三种方式,可以确定是底层的libObjc.dylib源码,那么现在去源码中看看吧!

    在源码中搜索objc_sync_enterobjc_sync_exit两个方法分析一下底层的源码实现:

    objc_sync_enter

    • objc_sync_enter


      objc_sync_enter

    objc_sync_exit

    • objc_sync_exit


      objc_sync_exit
    • 通过上面的源码发现,enter方法和exit方法的实现是相呼应的。

    • 加锁和解锁都会对obj进行判断,如果obj为空,则什么都不会做,通过在源码中搜索,并没有查到与objc_sync_nil()的相关实现。

    • 如果obj不为空,在enter方法中,会封装一个SyncData对象,并对调用mutex属性进行上锁lock();在exit方法时,同样获取对应的SyncData对象,然后调用data->mutex.tryUnlock()进行解锁。

    • SyncData是一个结构体,定义如下

    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;
    
    • struct SyncData* nextData:这个是一个单链表结构,其中包含了一个相同的数据结构
    • object:这里是使用了DisguisedPtr进行了包装,方便计算和传递
    • threadCount:线程的数量,有多少个线程对该对象进行加锁的操作
    • recursive_mutex_t mutex:递归互斥锁

    从以上信息可以知道@synchronized支持递归锁,并且支持多线程访问。

    那么底层是如何进行多线程操作的呢?又是如何递归,如何加锁的你?

    objc_sync_exit方法中获取data 是从id2data方法中获取的

    • id2data
      id2data方法
      这里主要是获取锁,和获取listp列表数据,通过不同缓存获取SyncData,还有其他的一些操作,重点看如下代码
    spinlock_t *lockp = &LOCK_FOR_OBJ(object);//获取锁
    SyncData **listp = &LIST_FOR_OBJ(object);//object的列表
    

    这是两个都是通过宏处理的,如下

    宏的定义
    从上面的代码可以发现StripedMap数据存储结构是重点,这是一个哈希表。见下面代码:
    StripedMap
    这里针对不同平台架构环境,提供了不同的容量,真机环境的容量StripeCount8,模拟环境的容量StripeCount64。而其元素为SyncListSyncList的数据结构是个结构体:
    struct SyncList {
        SyncData *data;
        spinlock_t lock;
    
        constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
    };
    

    从代码分析来看,而SyncData是一个链表结构,是哈希的拉链结构,如下

    哈希拉链结构

    举例分析

    写入下面这个代码测试:


    代码测试
    • 断点在 42行处,再单步跟踪进入源码里面,打印测试
      测试打印
      lldb调试打印结果来看,64data全是空的值,继续跟踪调试,会调用tls_get_direct方法,获取当前线程绑定的SyscData,那么断点继续往下跟踪看看,结果如何:
      tls_get_direct方法调用后
      因为是第一次进行加锁,这里的结果还是nil,继续往下走看看,从缓存中是否可以获取到呢?
      fetch_cache中也没有数据

    fetch_cache的缓存中,也没有数据,依然是为空,那么就会继续走下面的创建流程,如下:

    创建SyncData
    没有的话就会创建一个SyncData,并采用头插法将数据插入到对应listp头部
    采用头插法将数据插入到对应listp头部
    完成SyncData创建后,会绑定到当前线程上(一个线程只会绑定一个,并且绑定后不再改变),注意此时并没有保存到线程对应的缓存列表中。
    返回结果

    未完待续,下篇继续分析@synchronized,敬请期待!

    更多内容持续更新

    🌹 喜欢就点个赞吧👍🌹

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

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

    相关文章

      网友评论

        本文标题:iOS底层探索之多线程(十四)—关于@synchronized锁

        本文链接:https://www.haomeiwen.com/subject/wbediltx.html