iOS

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

2021-08-24  本文已影响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(@"当前车票已售罄");
    }

}

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

 @synchronized (self) {
         
         if (self.ticketCount > 0) {
              self.ticketCount--;
              sleep(0.1);
              NSLog(@"当前余票还剩：%lu张",(unsigned long)self.ticketCount);
         }else{
              NSLog(@"当前车票已售罄");
         }
    }

2. @synchronized分析

在 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。这里最重要的其实就是如下两个方法

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

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

3. 源码分析

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

在源码中搜索objc_sync_enter和objc_sync_exit两个方法分析一下底层的源码实现：

objc_sync_enter

objc_sync_exit

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;

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

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

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

spinlock_t *lockp = &LOCK_FOR_OBJ(object);//获取锁
SyncData **listp = &LIST_FOR_OBJ(object);//object的列表

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

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

    constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
};

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

哈希拉链结构

举例分析

写入下面这个代码测试：


代码测试

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

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

未完待续，下篇继续分析@synchronized，敬请期待！

更多内容持续更新

🌹 喜欢就点个赞吧👍🌹

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

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

上一篇下一篇

猜你喜欢

热点阅读