细说@synchronized和dispatch_once

工欲善其事,必先利其器

通常我们在实现单例时候都会使用synchronized或者dispatch_once方法,初始化往往是下面的样子:
使用synchronized方法实现:

使用dispatch_once方法实现:

性能差异

上面的这些写法大家应该都很熟悉,既然两种方式都能实现,我们来看看两者的性能差异,这里简单写了个测试的demo,使用两个方法分单线程跟多线程(采用dispatch_apply方式,性能相对较高)去访问一个单例对象一百万次,对比这期间的耗时,从iPod跟5s测试得到如下的结果

可以发现dispatch_once方法的性能要明显优于synchronized方法(多线程不采用dispathc_apply方式差距更明显),所以在实际的应用中我们可以多采用dispatch_once方式来实现单例。通常使用的时候了解这些就够了,不过想知道两者的具体差异就需要我们再迈进一步。

深入@synchronized(object)

翻看苹果的文档可以发现 @synchronized指令内部使用锁来实现多线程的安全访问,并且隐式添加了一个异常处理的handler,当异常发生时会自动释放锁。在stackoverflow上看到@synchronized指令其实可以转换成objc_sync_enter跟objc_sync_exit,可以在头文件中找到这两个函数:

根据注释文档,objc_sync_enter会根据需要给每个传进来的对象创建一个互斥锁并lock,然后objc_sync_exit的时候unlock,这样就可以通过这个锁来实现多线程的安全访问,所以结合苹果文档可以认为

等价于

庆幸的是苹果已经将objc-runtime这部分开源,所以我们可以更进一步了解内部的实现,源码在这里,有兴趣也可以自己去查阅,这里简单介绍一下。
让我们先来看看几个数据结构,其中有些涉及到缓存,我们就不去考虑了:

首先看看SyncData这个数据结构,包含一个指向object的指针,这个object对象就是我们@synchronized时传进来的对象,也包含一个跟object关联的递归互斥锁recursive_mutex_t,该锁用来互斥访问object对象;同时还包含一个指向下一个SyncData的指针nextData,可以看出SyncData是一个链表中的节点;至于threadCount,这个值标示有几个线程正在访问这个对象,当threadCount==0的时候,会重用该SyncData对象,这是为了节省内存。
接下来看看SyncList,SyncList其实就是一个链表,data指向第一个SyncData节点,lock则是为了多线程安全访问该链表。
最后看下sDataLists静态哈希表对象,它以obj的指针为key,对应的value为SyncList链表。
了解上面之后,我们就可以看看objc_sync_enter跟objc_sync_exit的具体实现(摘取部分代码)

简单来说,调用objc_sync_enter(obj)时,会根据obj指针在哈希表sDataLists对应的链表SyncList,然后在链表中查询对应obj的SyncData对象,如果查询不到则创建一个新的SyncData对象(包含创建跟obj相关的递归互斥锁)并添加到链表中,然后使用SyncData对象上锁;调用objc_sync_exit(obj)时,使用SyncData对象解锁,因此通过这个锁便可确保@synchronized之间的代码线程安全。

11458529-1c42de5d32202095

sDataLists
深入dispatch_once

探讨了synchronized之后,我们再来说说dispatch_once。

根据官方文档,dispatch_once可以用来初始化一些全局的数据,它能够确保block代码在app的生命周期内仅被运行一次,而且还是线程安全的,不需要额外加锁;predicate必须指向一个全局或者静态的变量,不过使用predicate的话结果是未定义的,不过predicate有啥作用,如何实现block在整个生命周期执行一次?那我们只能从源码查找(源码地址:once)。
不过在这之前先简要介绍一下:

  • bool __sync_bool_compare_and_swap (type ptr, type oldval type newval, …)
    提供原子的比较和交换操作,如果当前值
    ptr == oldval,就将newval写入*ptr,当比较赋值操作成功后返回true
  • *__sync_synchronize (…)
    调用这个函数会产生一个full memory barrier ,用于保证CPU按照我们代码编写的顺序来执行代码,比如:
  • type __sync_swap(type *ptr, type value, …)
    提供原子交换操作的函数,交换第一个跟第二个参数的值,然后返回交换前第一个参数的旧值。
  • _dispatch_hardware_pause()
    调用这个函数主要是暗示处理器不要做额外的优化处理等,提高性能,节省CPU时间,可以查看这里了解更多
  • 信号量
    信号量是一个非负整数,定义了两种原子操作:wait跟signal来进行访,信号量主要用于线程同步。当一个线程调用wait操作时,如果信号量的值大于0,则获得资源并将信号量值减一,如果等于0线程睡眠直到信号量值大于0或者超时;singal将信号量的值加1,如果这时候有正在等待的线程,唤醒该线程。

接下来看看具体代码,当我们调用dispatch_once时候,内部是调用dispatch_once_f函数,其中val就是外部传入的predicate值,ctxt为Block的指针,func则是Block内部具体实现的函数指针,由于源码比较短,所以我直接把源码贴出来(为了方便查看,有些不使用宏定义)。

让我们来看看dispatch_once是如何确保block只执行一次。简单来说,当线程A在调用执行block并设置predicate为DISPATCH_ONCE_DONE(~0l)期间,如果有其他线程也在调用disptach_once,则这些线程会等待,各线程对应的信号量会加入到信号量链表中,等predicate设置为DISPATCH_ONCE_DONE后,也就是block执行完了,会根据信号量链表唤醒各个线程使其继续执行。

12458529-2d1119321803ee9b

信号量链表.png

不过有一种临界情况,假如线程A在执行block,但是创建单例对象obj还未完成,这时候线程B获取该obj对象,此时obj=nil,而线程B在线程A将predicate设为DISPATCH_ONCE_DONE之后读取predicate,这是线程B会认为单例对象已经初始化完成,然后使用空的obj对象,这就会导致错误发生。因此dispatch_once会在执行完block之后会执行dispatch_atomic_maximally_synchronizing_barrier()调用,这个调用会执行一些cpuid指令,确保线程A创建单例对象obj以及置predicate为DISPATCH_ONCE_DONE的时间TimeA大于线程B进入block并读取predicate值的时间TimeB。

除此之外,每次调用dispatch_once的时候,都会先判断predicate的值是否是~0l(也就是DISPATCH_ONCE_DONE),如果是则意味着block已经执行过了,便不再执行,代码如下:

让我们看看这里面的__builtin_expect((x), (v)),这又是一个优化的地方。。。

由于dispatch_once的只执行block一次,所以我们更期望的是已经block已经执行完了,也就是predict的值为~0l的可能性更大。
现在我们清楚dispatch_once是如何确保block只执行一次了,关键就在predict这个值,通过比较这个值等于0或者~0l来判断block是否执行过,这也就是为啥我们需要将这个值设为static或者全局的缘故,因为各个线程都要去访问这个predict,有兴趣的可以试试把predicate的初始值设为非0或者非静态全局变量会发生什么~~

总结

通过上面的分析,我们知道@synchronized采用的是递归互斥锁来实现线程安全,而dispatch_once的内部则使用了很多原子操作来替代锁,以及通过信号量来实现线程同步,而且有很多针对处理器优化的地方,甚至在if判断语句上也做了优化(逼格有点高),使得其效率有很大的提升,虽然其源码很短,但里面包含的东西却很多,所以苹果也推荐使用dispatch_once来创建单例。通过这个简短的dispatch_once,你也可以清楚为什么GCD的性能会这么高了,感兴趣可以再去看看libdispatch的其它源码。。

参考

objc-sync
synchronized
dispatch_once
Built-in functions for atomic memory access
__builtin_expect

1 收藏 评论

可能感兴趣的话题



直接登录
跳到底部
返回顶部