起因

这周开发过程中遇到一个奇怪的现象，即在某个页面一直卡住停留，造成卡死。而又没有立即崩溃，等待一会儿后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的内部流程有利于在使用中规避隐藏的问题。