起因
这周开发过程中遇到一个奇怪的现象，即在某个页面一直卡住停留，造成卡死。而又没有立即崩溃，等待一会儿后crash了，当即猜想是陷入了死锁或死循环里，于是开始排查，最终发现是由于dispatch_once滥用导致死锁。由于项目代码过于复杂，现写了个demo总结。
demo
1、创建两个单例（dispatch_once方式）
NSString *const ManagerOneRefreshNotification = @"ManagerOneRefreshNotification";
@implementation ManagerOne
+ (ManagerOne *)shareInstance {
static ManagerOne *shareInstance = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
shareInstance = [[ManagerOne alloc] init];
});
return shareInstance;
}
- (instancetype)init {
if (self = [super init]) {
self.unReadCount = 1;
[[NSNotificationCenter defaultCenter] postNotificationName:ManagerOneRefreshNotification object:nil];
}
return self;
}
@implementation ManagerTwo
+ (ManagerTwo *)shareInstance {
static ManagerTwo *shareInstance = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
shareInstance = [[ManagerTwo alloc] init];
});
return shareInstance;
}
- (instancetype)init {
if (self = [super init]) {
self.unReadCount = 2;
[[NSNotificationCenter defaultCenter] postNotificationName:ManagerTwoRefreshNotification object:nil];
}
return self;
}
2、在他们初始化后都会利用通知回调给viewcontroller进行刷新
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(refresh) name:ManagerOneRefreshNotification object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(refresh) name:ManagerTwoRefreshNotification object:nil];
[ManagerOne shareInstance];
}
- (void)refresh {
NSLog(@"unReadCount:%d", [ManagerOne shareInstance].unReadCount + [ManagerTwo shareInstance].unReadCount);
}
3、然后就会crash
dispatch_once_crash.png
分析
从左边的调用栈中多次出现dispatch_once和shareInstance可以看出是进入了死循环。根据调用栈中出现的_dispatch_client_callout以及_dispatch_gate_wait_slow猜想可能是dispatch_once_f函数造成了信号量的永久等待，代码更正思路好做，但是为何会造成死锁呢？带着疑问从dispatch_once的源码里寻找答案。
dispatch_once源码
Apple对于dispatch_once的源码地址
#include "internal.h"
#undef dispatch_once
#undef dispatch_once_f
typedef struct _dispatch_once_waiter_s {
volatile struct _dispatch_once_waiter_s *volatile dow_next;
dispatch_thread_event_s dow_event;
mach_port_t dow_thread;
} *_dispatch_once_waiter_t;
#define DISPATCH_ONCE_DONE ((_dispatch_once_waiter_t)~0l)
#ifdef __BLOCKS__
void
dispatch_once(dispatch_once_t *val, dispatch_block_t block)
{//第一步：我们调用dispatch_once入口，接下来去看最下面dispatch_once_f的定义
dispatch_once_f(val, block, _dispatch_Block_invoke(block));
}
#endif
#if DISPATCH_ONCE_INLINE_FASTPATH
#define DISPATCH_ONCE_SLOW_INLINE inline DISPATCH_ALWAYS_INLINE
#else
#define DISPATCH_ONCE_SLOW_INLINE DISPATCH_NOINLINE
#endif
DISPATCH_ONCE_SLOW_INLINE
static void
dispatch_once_f_slow(dispatch_once_t *val, void *ctxt, dispatch_function_t func)
{
#if DISPATCH_GATE_USE_FOR_DISPATCH_ONCE
dispatch_once_gate_t l = (dispatch_once_gate_t)val;
if (_dispatch_once_gate_tryenter(l)) {
_dispatch_client_callout(ctxt, func);
_dispatch_once_gate_broadcast(l);
} else {
_dispatch_once_gate_wait(l);
}
#else//第三步：主要的流程（为什么走#else请看注解二）
_dispatch_once_waiter_t volatile *vval = (_dispatch_once_waiter_t*)val;
struct _dispatch_once_waiter_s dow = { };
_dispatch_once_waiter_t tail = &dow, next, tmp;
dispatch_thread_event_t event;
//首次更改请求
if (os_atomic_cmpxchg(vval, NULL, tail, acquire)) {
dow.dow_thread = _dispatch_tid_self();
//调用dispatch_once内block回调
_dispatch_client_callout(ctxt, func);
//利用while循环不断处理未完成的更改请求，直到所有更改结束
next = (_dispatch_once_waiter_t)_dispatch_once_xchg_done(val);
while (next != tail) {
tmp = (_dispatch_once_waiter_t)_dispatch_wait_until(next->dow_next);
event = &next->dow_event;
next = tmp;
_dispatch_thread_event_signal(event);
}
} else {//非首次更改请求
_dispatch_thread_event_init(&dow.dow_event);
next = *vval;
for (;;) {
//遍历每一个后续请求，如果状态已经是Done，直接进行下一个，同时该状态检测还用于避免在后续wait之前，信号量已经发出(signal)造成的死锁
if (next == DISPATCH_ONCE_DONE) {
break;
}
//如果当前dispatch_once执行的block没有结束，那么就将这些后续请求添加到链表当中
if (os_atomic_cmpxchgv(vval, next, tail, &next, release)) {
dow.dow_thread = next->dow_thread;
dow.dow_next = next;
if (dow.dow_thread) {
pthread_priority_t pp = _dispatch_get_priority();
_dispatch_thread_override_start(dow.dow_thread, pp, val);
}
_dispatch_thread_event_wait(&dow.dow_event);
if (dow.dow_thread) {
_dispatch_thread_override_end(dow.dow_thread, val);
}
break;
}
}
_dispatch_thread_event_destroy(&dow.dow_event);
}
#endif
}
DISPATCH_NOINLINE
void
dispatch_once_f(dispatch_once_t *val, void *ctxt, dispatch_function_t func)
{
#if !DISPATCH_ONCE_INLINE_FASTPATH
if (likely(os_atomic_load(val, acquire) == DLOCK_ONCE_DONE)) {
return;
}
#endif //第二步：进入dispatch_once_f_slow(这个宏判断请看注解一)
return dispatch_once_f_slow(val, ctxt, func);
}
注解一：
DISPATCH_ONCE_INLINE_FASTPATH这个宏的值由CPU架构决定，__x86_64__（64位），__i386__（32位），__s390x__（运行在IBM z系统(s390x)，可能Apple和IBM比较熟，给他留后门了），以及__APPLE__这个就无从得知了，可能是Apple自身的平台架构，这些情况下DISPATCH_ONCE_INLINE_FASTPATH = 1，所以大部分情况也就是1了。
#if defined(__x86_64__) || defined(__i386__) || defined(__s390x__)
#define DISPATCH_ONCE_INLINE_FASTPATH 1
#elif defined(__APPLE__)
#define DISPATCH_ONCE_INLINE_FASTPATH 1
#else
#define DISPATCH_ONCE_INLINE_FASTPATH 0
#endif
注解二：
DISPATCH_GATE_USE_FOR_DISPATCH_ONCE这个宏的值在lock.h中有定义：
#pragma mark - gate lock
#if HAVE_UL_UNFAIR_LOCK || HAVE_FUTEX
#define DISPATCH_GATE_USE_FOR_DISPATCH_ONCE 1
#else
#define DISPATCH_GATE_USE_FOR_DISPATCH_ONCE 0
#endif
而HAVE_UL_UNFAIR_LOCK的值和HAVE_FUTEX的值也在lock.h中有定义：
#ifdef __linux__
#define HAVE_FUTEX 1
#else
#define HAVE_FUTEX 0
#endif
#ifdef UL_UNFAIR_LOCK
#define HAVE_UL_UNFAIR_LOCK 1
#endif
从上面的分析可以看出：
1、dispatch_once不止是简单的执行一次，如果再次调用会进入非首次更改的模块，如果有未DONE的请求会被添加到链表中
2、所以dispatch_once本质上可以接受多次请求，会对此维护一个请求链表
3、如果在block执行期间，多次进入调用同类的dispatch_once函数（即单例函数），会导致整体链表无限增长，造成永久性死锁
4、对于开始问题大致上和 A -> B -> A的流程类似，理解dispatch_once的内部流程有利于在使用中规避隐藏的问题。
