这是我参与8月更文挑战的第22天，活动详情查看：8月更文挑战
对于多线程你了解多少？对于锁你又了解多少？锁的原理你又知道吗？
iOS底层探索之多线程(六)—GCD源码分析(sync 同步函数、async 异步函数)
iOS底层探索之多线程(八)—GCD源码分析(函数的同步性、异步性、单例)
回顾
在上篇博客中，介绍了 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 block
recursive_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，敬请期待！
更多内容持续更新
🌹 喜欢就点个赞吧👍🌹
🌹 觉得有收获的，可以来一波，收藏+关注，评论 + 转发，以免你下次找不到我😁🌹
🌹欢迎大家留言交流，批评指正，互相学习😁，提升自我🌹
