dispatch_once分析
在iOS开发中,我们经常使用dispatch_once去定义一个单例,来保证对象的唯一性,不过我们是否去了解过dispatch_once是如何在多线程情况下保证生成对象的唯一性呢?例如,我们经常用下面的代码块生成一个单例。
+ (instancetype)sharedInstance {
static XXObject *_instance;
static dispatch_once_t _predicate;
dispatch_once(&_predicate, ^{
_instance = [[XXObject alloc] init];
});
return _instance;
}
这段代码中涉及到两个关键词,一个是dispatch_once_t变量
,一个是dispatch_once函数
,下面我们逐个分析
dispatch_once_t变量
在once.h中找到其定义如下: typedef long dispatch_once_t;
dispatch_once_t原来是一个长整型!真是让人措手不及…
dispatch_once函数
void dispatch_once(dispatch_once_t *val, void (^block)(void)){
struct Block_basic *bb = (void *)block;
dispatch_once_f(val, block, (void *)bb->Block_invoke);
}
可以看到,在dispatch_once
中,生成一个Block_basic指针,指向了block,并把其Block_invoke函数指针传递给了dispatch_once_f
相信大家一定有疑问,Block_basic
和Block_invoke
是什么东西?很遗憾,源码中找不到,我们可以推测一下:
Block_basic
首先是一个结构体,它定义的指针可以指向void (^block)(void)
类型的block
Block_invoke
的字面意思是触发一个block
,可以参考以下代码理解
void _dispatch_call_block_and_release(void *block)
{
void (^b)(void) = block;
b();
Block_release(b);
}
接下来分析核心函数dispatch_once_f
:
void dispatch_once_f(dispatch_once_t *val, void *ctxt, void (*func)(void *)){
volatile long *vval = val;
if (dispatch_atomic_cmpxchg(val, 0l, 1l)) {
func(ctxt); // block真正执行
dispatch_atomic_barrier();
*val = ~0l;
}
else
{
do
{
_dispatch_hardware_pause();
} while (*vval != ~0l);
dispatch_atomic_barrier();
}
}
-
1、
dispatch_atomic_cmpxchg
,它是一个宏定义,原型为__sync_bool_compare_and_swap((p), (o), (n))
,这是LockFree给予CAS的一种原子操作机制,原理就是 如果p==o,那么将p设置为n,然后返回true;否则,不做任何处理返回false -
2、在多线程环境中,如果某一个线程A首次进入
dispatch_once_f
,*val==0,这个时候直接将其原子操作设为1,然后执行传入dispatch_once_f
的block,然后调用dispatch_atomic_barrier
,最后将*val的值修改为~0。 -
3、
dispatch_atomic_barrier
是一种内存屏障,所谓内存屏障,从处理器角度来说,是用来串行化读写操作的,从软件角度来讲,就是用来解决顺序一致性问题的。编译器不是要打乱代码执行顺序吗,处理器不是要乱序执行吗,你插入一个内存屏障,就相当于告诉编译器,屏障前后的指令顺序不能颠倒,告诉处理器,只有等屏障前的指令执行完了,屏障后的指令才能开始执行。所以这里dispatch_atomic_barrier
能保证只有在block执行完毕后才能修改*val的值。 -
4、在首个线程A执行block的过程中,如果其它的线程也进入
dispatch_once_f
,那么这个时候if的原子判断一定是返回false,于是走到了else分支,于是执行了do~while循环,其中调用了_dispatch_hardware_pause
,这有助于提高性能和节省CPU耗电,pause就像nop,干的事情就是延迟空等的事情。直到首个线程已经将block执行完毕且将*val修改为~0,调用dispatch_atomic_barrier
后退出。这么看来其它的线程是无法执行block的,这就保证了在dispatch_once_f
的block的执行的唯一性,生成的单例也是唯一的。
dispatch_once死锁
参考案例 : 单例滥用 - dispatch_once死锁造成crash(dispatch_once源码分析) - 简书
上面说了这么多,是不是说使用dispatch_once
写单例就可以高枕无忧了呢?
实际上并非如此,不正当地使用dispatch_once
可能会造成死锁:
死锁方式1:
1、某线程T1()调用单例A,且为应用生命周期内首次调用,需要使用dispatch_once(&token, block())初始化单例。
2、上述block()中的某个函数调用了dispatch_sync_safe,同步在T2线程执行代码
3、T2线程正在执行的某个函数需要调用到单例A,将会再次调用dispatch_once。
4、这样T1线程在等block执行完毕,它在等待T2线程执行完毕,而T2线程在等待T1线程的dispatch_once执行完毕,造成了相互等待,故而死锁死锁方式2:
1、某线程T1()调用单例A,且为应用生命周期内首次调用,需要使用dispatch_once(&token, block())初始化单例;
2、block中可能掉用到了B流程,B流程又调用了C流程,C流程可能调用到了单例A,将会再次调用dispatch_once;
3、这样又造成了相互等待。
所以在使用写单例时要注意:
- 1、初始化要尽量简单,不要太复杂;
- 2、尽量能保持自给自足,减少对别的模块或者类的依赖;
- 3、单例尽量考虑使用场景,不要随意实现单例,否则这些单例一旦初始化就会一直占着资源不能释放,造成大量的资源浪费。
dispatch_once也可以通过锁来实现,使用dispatch_semaphore,NSLock,@synchronized 这些都可以实现,但是效率没有dispatch_once高。实测也是可以的。
// 方式1,使用synchronized最简单
+ (instancetype)synchronizedManager {
static Person * m = nil;
if (m == nil) {
@synchronized (self) {
if (m == nil) {
// 模拟耗时操作,给其他线程进入提供机会
sleep(3);
m = [[self alloc] init];
NSLog(@"synchronizedManager 只执行一次是对的");
}
}
}
return m;
}
// 方式2,使用dispatch_semaphore,需要多一些操作,NSLock同理
static dispatch_semaphore_t sem = nil;
+ (void)initialize {
if (sem == nil) {
sem = dispatch_semaphore_create(1);
}
}
+ (instancetype)semaphoreManager {
static Person * m = nil;
if (m == nil) {
dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);
if (m == nil) {
// 模拟耗时操作,给其他线程进入提供机会
sleep(3);
m = [[self alloc] init];
NSLog(@"semaphoreManager 只执行一次是对的");
}
dispatch_semaphore_signal(sem);
}
return m;
}
解释一下为什么要判断2次 m == nil ?
因为加锁/解锁是一个耗时的操作, 获取单例可能是频繁的操作, 每次都加锁/解锁 浪费性能, 所以有 了第一个判断m == nil;
为什么在锁内部还需要一次判断呢?
因为外界通过多线程调用单例方法, 第一次的时候可能有多个线程都通过了外层判断, 然后线程A 加锁成功, 创建好单例对象之后释放锁, 线程B在外界正好拿到锁, 又创建一次单例对象, 此时线程A和线程B创建的单例对象就不是一个了,在锁内部在判断一次 m == nil, 可能防止这种情况.