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

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

@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 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锁你了解多少?)