iOS底层探索之多线程(十四)—关于@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 里面写入下面这行代码

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

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

objc_sync_enter
objc_sync_exit
下符号断点查看

从上面图中运行结果来看，断点走了下的符号断点objc_sync_enter处， 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_enter

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 blockrecursive_mutex_t mutex;
} SyncData;

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

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

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

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

id2data

这里主要是获取锁，和获取listp列表数据，通过不同缓存获取SyncData，还有其他的一些操作，重点看如下代码

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

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

从上面的代码可以发现StripedMap数据存储结构是重点，这是一个哈希表。见下面代码：

这里针对不同平台架构环境，提供了不同的容量，真机环境的容量StripeCount为8，模拟环境的容量StripeCount为64。而其元素为SyncList，SyncList的数据结构是个结构体：

struct SyncList {SyncData *data;spinlock_t lock;constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
};

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

举例分析

写入下面这个代码测试：

断点在 42行处，再单步跟踪进入源码里面，打印测试

从 lldb调试打印结果来看，64个 data全是空的值，继续跟踪调试，会调用tls_get_direct方法，获取当前线程绑定的SyscData，那么断点继续往下跟踪看看，结果如何：

因为是第一次进行加锁，这里的结果还是nil，继续往下走看看，从缓存中是否可以获取到呢？

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

没有的话就会创建一个SyncData，并采用头插法将数据插入到对应listp头部

完成SyncData创建后，会绑定到当前线程上（一个线程只会绑定一个，并且绑定后不再改变），注意此时并没有保存到线程对应的缓存列表中。

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

更多内容持续更新