iOS synchronized底层原理分析
Posted 京东零售技术
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了iOS synchronized底层原理分析相关的知识,希望对你有一定的参考价值。
@synchronized是我们ios开发中常见的锁,其本质是递归锁,其作用是创建一个互斥锁,保证此时没有其他线程对传入的对象进行修改,保证代码的安全性。开发中不需要程序员手动加解锁,不会产生死锁问题。对于@synchronized的使用,我们在创建单例和防止多线程同时执行同一段代码时候使用,相比于使用NSLock创建锁对象、加锁、解锁来说,@synchronized的使用更方便,并且其可读性更高。
main(argc, * argv[]) * appDelegateClassName;
appDelegateClassName =
(appDelegateClassName)
UIApplicationMain(argc, argv, nil, appDelegateClassName);
通过汇编调试查看其代码运行截图如下:
从截图中我们可以看到在@synchonized执行打印前后分别调用了objc_sync_enter和objc_sync_exit.
通过对上述main.m文件clang编译代码其截图如下:
从clang编译后的代码我们可以看到objc_sync_enter(_sync_obj)这个是和我们断点汇编查看中是一样的,其中_sync_objc就是我们通过小括号传过来的参数;然后是try逻辑,其内部是有一个结构体_SYNC_EXIT,这个结构体内部包含构造方法_SYNC_EXIT(id arg)和析构方法~_SYNC_EXIT();调用_sync_exit(_sync_obj)方法,初始化结构体_SYNC_EXIT(id arg);NSLog()函数的执行是我们要加锁的代码,当try执行完成之后,会调用析构方法~_SYNC_EXIT(),最终执行objc_sync_exit(sync_exit)方法;如果发生异常就会调用objc_exception_throw(rethrow)方法,去执行异常的跑出;至此@synchronized的整体的调用顺序我们就可以简单理解为:objc_sync_enter(_sync_obj)----->NSLog()方法(我们要加锁的逻辑代码)---->objc_sync_exit(sync_exit);
接下来我们重点查看一下objc_sync_enter()和objc_sync_exit()
查看objc_sync_enter源码我们从libobjc中查看,其方法截图如下:
我们查看源码可知objc_sync_enter(id obj)中参数obj就是我们通过@synchronized()小括号传进来的参数;首先会判断传进来的参数obj是否存在,如果不存在,则会调用objc_sync_nil(),查看其内部其实是什么也没做的,如果存在就会将传入的obj 通过id2data去创建一个SyncData的结构体指针,然后通过data->mutex.lock()来实现上锁,其中mutex就是用于保证线程在某一时刻只有该线程可以访问对象,获取锁操作失败,线程会进入睡眠,所以@synchronized是一种互斥锁。
查看objc_sync_exit()源码,其截图如下:
从objc_sync_exit(id obj)源码中可知也会判断obj是否存在,如果不存在同样不会做任何事,如果存在同样会通过id2data传入obj参数获取SyncData *data,如果data存在会通过data->mutex.tryUnlock()去解锁。
我们从objc_sync_enter()和objc_sync_exit()源码可知其都调用了id2data()方法获取SyncData结构数据,其中两个方法只是入参不同,接下来我们看一下SyncData的数据结构:
从SyncData定义来看,可知它是一个结构体,其中第一个成员变量是指向下一个SyncData,可见其是一个链表结构,第二个成员变量object是传入的obj;第三个指当前有多少个线程在使用这个block;第四个mutex是互斥锁,代表递归属性;
接下来我们查看一下id2data()方法的源码,由于id2data()方法中源码很长,我将其分为4部分给大家介绍,有兴趣的同学可以查看完整源码:
1、 快速缓存中查找,如果支持快速缓存则从缓存中读取,其代码注释及截图如下:
快速缓存中查找是从线程中读取数据data,如果与传入的object相同,则赋值给result,并且将lockCount++或lockCount--,调用tls_set_direct()方法更新到制定的key中,如果lockCount为0时,则会释放线程缓存,将缓存值SYNC_DATA_DIRECT_KEY置为NULL,同时更新result下的线程数。
2、 线程缓存,快速缓存未找到就会从线程缓存中读取线程和任务,其代码注释及截图如下:
在说线程缓存之前,我们先来了解一下SyncCache,看一下其数据结构:
从其结构来看我们知道SyncCache是一个结构体对象,用来存储线程,list[0]表示当前线程的链表data,其存储着SyncData结构的data和lockCount.
从代码中我们可以看到其实线程缓存的读取任务和快速缓存逻辑是一样,都是最终去查询syncdata和lockCount,只是查询时的结构不同,内存缓存是从SyncCache中去读取的,其中fetch_cache()方法就是缓存的查询和创建,有兴趣的同学可以查看一下该方法。针对读取大家可以看一下下图加深点印象:
3、 循环遍历,所有缓存都找不到,循环遍历每个线程和任务进行操作。
这里循环遍历是在缓存中都不在下进行,从全局的listp链表中寻找Syncdata,如果遍历也没找到,有空节点的话,就会给空节点进行赋值。
4、 done, 如果不是当前对象或者进行中抛出异常,如果正常存在则会存入快速缓存和线程缓存中便于下一次查找。代码注释及截图如下:
至此id2data()方法的过程讲解完成,其实总的来说该方法就是根据传入的object去找到SyncData的过程,先从快速缓存中查找,再从线程缓存SyncCache中查找,缓存中不存在就会从全局链表listp中查找,如果链表中也不存在,就会自己创建一个,最终存储在快速缓存和线程缓存中方便下次查找。其过程图如下:
针对前面所说的问题,相信大家看过源码之后心中已有答案了吧。@synchronized中传入object的内存地址,被用作key,通过一定的hash函数映射到一个系统全局维护的递归锁中,所以不论我们传什么值,只要有内存地址都可以达到同步锁的效果;当你在@synchronized中传入nil时,相当于你没有进行加锁操作,同时你的代码也不会是线程安全的。@synchronized使用起来很简单方便,但是其内部实现起来还是很复杂的,需要注意的是我们要在使用过程中注意传入object的生命周期,如果参数传nil,其同步锁的效果也将失去。至此@synchronized原理介绍及注意事项先到这里,欢迎大家沟通和指正。
iOS底层探索之多线程(十五)—@synchronized源码分析
对于多线程你了解多少?对于锁你又了解多少?锁的原理你又知道吗?
iOS底层探索之多线程(六)—GCD源码分析(sync 同步函数、async 异步函数)
iOS底层探索之多线程(八)—GCD源码分析(函数的同步性、异步性、单例)
iOS底层探索之多线程(十四)—关于@synchronized锁你了解多少?
1. 回顾
在上一篇博客中,已经分析了第一次加锁,data
是空的,最后会创建SyncData
并绑定到当前线程上(一个线程只会绑定一个,并且绑定后不再改变),注意此时并没有保存到线程对应的缓存列表中。
2. 源码分析
单线程情况
那么现在去看看第二次加锁,也就是断点在44
行时,进行跟踪调试。
那么继续
单步调式
进入源码里面,断点在id2data
方法里面再进行lldb
的调式进行分析。
从图中控制台 lldb
的调试结果来看,第二次进行加锁
时,data
里面是有数据的了。那么继续过断点看看,缓存里面的情况:
此时缓存里面也有数据了,和上面打印的结果是一模一样,都是data = 0x0000000100837d40
。然后会继续判断,传入对象是否是和缓存里面的一样。
if (data->object == object) {
// Found a match in fast cache.
uintptr_t lockCount;
result = data;
lockCount = (uintptr_t)tls_get_direct(SYNC_COUNT_DIRECT_KEY);
if (result->threadCount <= 0 || lockCount <= 0) {
_objc_fatal("id2data fastcache is buggy");
}
如果是同一个对象,就会获取lockCount
,lockCount
和threadCount
是否小于等于 0
进行判断,如果小于 0
则会报错"id2data fastcache is buggy"
-
如果是
ACQUIRE
则会lockCount++
,再进行锁
一次,说明当前对象锁了两次,如下:
-
如何是
RELEASE
则会lockCount--
,如果lockCount == 0
,则会从线程空间缓存移除,这里也可以体现多线程的特性,从这句OSAtomicDecrement32Barrier(&result->threadCount)
代码可以看出,这是对线程进行释放。
断点继续,看看第三次加锁的情况,如下:
因为是对同一个对象,进行了重复的操作,加锁了3
次,lockCount
也是等于 3
的,这也提现了拉链法,如下:
因为是同一个对象,每次加锁,都会创建一个
SyncData
,就一直往后拉着,通过一个链表来存。
以上都是对一个对象进行重复的递归加锁,那如果是不同对象呢?
不同对象也是类似的,就和上面那个结构图一样,每个对象会创建一个拉链,同一个对象的就存在一个链表里面,这里就不再进行举例了,感兴趣的老铁可以自行测试,源码戳这里
多线程递归情况
那么现在通过多线程加锁会怎么样呢?测试代码如下:
断点从 52
行开始,进入到源码里面跟踪调式,这时候进入id2data
方法,此时哈希表中的数据个数为2
,也就是外层线程添加的两个SyncData
,如下图:
继续跟踪代码,从线程中获取其绑定的SyncData
,此时为NULL
,因为是新的线程,还没有加过锁,所以绑定数据为空,fastCacheOccupied=NO
然后会继续往下走,接着从缓存列表fetch_cache
中获取对应的·SyncData·,也是·NULL·,这里的缓存列表也是和线程一一对应的起来的,都是空。
继续跟踪流程,接着会进行线程threadCount++
操作,如下图:
这里会从listp
中获取对应的数据,在外层线程中,已经添加了jp
和jp2
对应的SyncData
,这里是可以获取到的,并且会对多线程操作,使得threadCount
加1
操作,此时对应的线程数会从 1
变成2
,从上图调试打印的结果可以很明显的看到。
只要遇到新开线程,开始加锁,tls
和cache
一定是空,肯定是listp
中查找,或者是创建。一个线程中第一个添加的object
一定会绑定到tls
中,并且在当前线程中不会改变。如果tls
已经完成设置,之后添加的SyncData
都会添加到缓存列表中。
objc_sync_exit
流程和这个相反,同样会调用id2data
方法,获取SyncData
,对lockCount
和threadCount
进行减操作。如果count
等于0
,则会从相应的绑定关系和缓存列表中移除。
使用@synchronized的注意事项
- 参数不传
nil
- 参数最好传
self
,方便存储和释放,如果是传入一个这种JPStudent *jp = [[JPStudent alloc]init]
的,这个jp
是一个临时的变量,如果有个多个这种,就会有多个拉链,耗费内存和性能,只使用一个self
就只有一个拉链,虽然真机环境下,只有8
个,但是已经够用了,即便不够用,系统也会及时释放回收的。
- 在之前的博客中进行的
@synchronized
测试,为什么模拟器下性能比真机差呢?就是上图中64
的原因,模拟器拉链比较多,耗费内存和性能。
3. 总结
1: synchronized
哈希表 - 拉链法 存储SyncData
2: sDataLists
里面是一个 array
存储的是 SyncList
,SyncList
里面是绑定的object
3: objc_sync_enter / exit
对称 递归锁
4: 两种存储 : TLS
/ Cache
5: 第⼀次的时候 SyncData
才用头插法 -链表 ,标记 thracount = 1
6: 然后下次再进来会判断是不是同⼀个对象
7: 是同一个对象TLS --> lockCount ++
8: 不是同一个的话TLS
找不到 就会去创建一个SyncData
则threadCount ++
9: objc_sync_exit
的话就是lockCount--
和 threadCount--
@synchronized : 可重⼊递归 、多线程
1: 多线程是通过TLS
保障threadCount
有多少条线程对这个锁对象加锁
2: 可重入递归是通过lockCount ++
来表示进来锁了多少次
- 补充
TLS
线程局部存储(Thread Local Storage,TLS
): 是操作系统为线程单独提供的私有空间,通常只有有限的容量。Linux
系统下通常通过pthread
库中的
pthread_key_create()、
pthread_getspecific()、
pthread_setspecific()、
pthread_key_delete()等方法。
更多内容持续更新
🌹 喜欢就点个赞吧👍🌹
🌹 觉得有收获的,可以来一波,收藏+关注,评论 + 转发,以免你下次找不到我😁🌹
🌹欢迎大家留言交流,批评指正,互相学习😁,提升自我🌹
以上是关于iOS synchronized底层原理分析的主要内容,如果未能解决你的问题,请参考以下文章
并发复习 ---- Synchronized底层原理深入分析