问题
最近排查一个crash 问题，读了一下crash Log以后，发现堆栈报的错误信息非常奇怪。相似在对一个单例对象发消息时出错了
符号化后的信息：
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001ad6eeda4
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [0]
Triggered by Thread: 0
Thread 0 name:
Thread 0 Crashed:
0 libdispatch.dylib 0x00000001ad6eeda4 _dispatch_gate_wait_slow$VARIANT$mp + 164 (lock.c:599)
1 libdispatch.dylib 0x00000001ad6efa9c dispatch_once_f$VARIANT$mp + 132 (once.c:60)
2 libdispatch.dylib 0x00000001ad6efa9c dispatch_once_f$VARIANT$mp + 132 (once.c:60)
3 today 0x00000001039f96bc +[xxxxx sharedInstance] + 56 (once.h:75)
4 today 0x00000001039f42f4 -[xxxxx init] + 104 (xxxxx.m:40)
5 today 0x00000001039f4274 __37+[xxxxx sharedInstance] _block_invoke + 40
首先关注Termination Reason: Namespace SIGNAL, Code 0x5。好像是在说空指针问题，但是对于单例对象会返回空指针吗？
从中我们可以发现，在这段调用栈中，出现了多次敏感字样sharedInstance和dispatch_once_f字样。
而我们的单例用demo揭示如下：
@implementation ManageA
+ (ManageA *)sharedInstance
{
static ManageA *manager = nil;
static dispatch_once_t token;
dispatch_once(&token, ^{
manager = [[ManageA alloc] init];
});
return manager;
}
- (instancetype)init
{
self = [super init];
if (self) {
[ManageB sharedInstance];
}
return self;
}
@end
@implementation ManageB
+ (ManageB *)sharedInstance
{
static ManageB *manager = nil;
static dispatch_once_t token;
dispatch_once(&token, ^{
manager = [[ManageB alloc] init];
});
return manager;
}
- (instancetype)init
{
self = [super init];
if (self) {
[ManageA sharedInstance];
}
return self;
}
假设
在查阅相关资料后，感觉是dispatch_once_f函数造成了信号量的永久等待，从而引发死锁。那么，为什么dispatch_once会死锁呢？以前说的最安全的单例构造方式还正确不正确呢？
所以，我们一起来看看下面关于dispatch_once的源码分析。
这时开始考虑难道单例dispatch_once的创建不安全。（这好像和我们对dispatch_once的认知相悖）
dispatch_once源码分析
从libdispatch获取最新版本代码，进入对应的文件once.c。去除注释后代码如下，共66行代码，但是真的是有很多奇妙的地方。
#include "internal.h"
#undef dispatch_once
#undef dispatch_once_f
struct _dispatch_once_waiter_s {
volatile struct _dispatch_once_waiter_s *volatile dow_next;
_dispatch_thread_semaphore_t dow_sema;
};
#define DISPATCH_ONCE_DONE ((struct _dispatch_once_waiter_s *)~0l)
#ifdef __BLOCKS__
// 1. 我们的应用程序调用的入口
void
dispatch_once(dispatch_once_t *val, dispatch_block_t block)
{
struct Block_basic *bb = (void *)block;
// 2. 内部逻辑
dispatch_once_f(val, block, (void *)bb->Block_invoke);
}
#endif
DISPATCH_NOINLINE
void
dispatch_once_f(dispatch_once_t *val, void *ctxt, dispatch_function_t func)
{
struct _dispatch_once_waiter_s * volatile *vval =
(struct _dispatch_once_waiter_s**)val;
// 3. 地址类似于简单的哨兵位
struct _dispatch_once_waiter_s dow = { NULL, 0 };
// 4. 在Dispatch_Once的block执行期进入的dispatch_once_t更改请求的链表
struct _dispatch_once_waiter_s *tail, *tmp;
// 5.局部变量，用于在遍历链表过程中获取每一个在链表上的更改请求的信号量
_dispatch_thread_semaphore_t sema;
// 6. Compare and Swap（用于首次更改请求）
if (dispatch_atomic_cmpxchg(vval, NULL, &dow)) {
dispatch_atomic_acquire_barrier();
// 7.调用dispatch_once的block
_dispatch_client_callout(ctxt, func);
dispatch_atomic_maximally_synchronizing_barrier();
//dispatch_atomic_release_barrier(); // assumed contained in above
// 8. 更改请求成为DISPATCH_ONCE_DONE(原子性的操作)
tmp = dispatch_atomic_xchg(vval, DISPATCH_ONCE_DONE);
tail = &dow;
// 9. 发现还有更改请求，继续遍历
while (tail != tmp) {
// 10. 如果这个时候tmp的next指针还没更新完毕，等一会
while (!tmp->dow_next) {
_dispatch_hardware_pause();
}
// 11. 取出当前的信号量，告诉等待者，我这次更改请求完成了，轮到下一个了
sema = tmp->dow_sema;
tmp = (struct _dispatch_once_waiter_s*)tmp->dow_next;
_dispatch_thread_semaphore_signal(sema);
}
} else {
// 12. 非首次请求，进入这块逻辑块
dow.dow_sema = _dispatch_get_thread_semaphore();
for (;;) {
// 13. 遍历每一个后续请求，如果状态已经是Done，直接进行下一个
// 同时该状态检测还用于避免在后续wait之前，信号量已经发出(signal)造成
// 的死锁
tmp = *vval;
if (tmp == DISPATCH_ONCE_DONE) {
break;
}
dispatch_atomic_store_barrier();
// 14. 如果当前dispatch_once执行的block没有结束，那么就将这些
// 后续请求添加到链表当中
if (dispatch_atomic_cmpxchg(vval, tmp, &dow)) {
dow.dow_next = tmp;
_dispatch_thread_semaphore_wait(dow.dow_sema);
}
}
_dispatch_put_thread_semaphore(dow.dow_sema);
}
}
根据以上注释对源代码的分析，我们可以大致知道如下几点：
dispatch_once并不是简单的只执行一次那么简单
dispatch_once本质上可以接受多次请求，会对此维护一个请求链表
如果在block执行期间，多次进入调用同类的dispatch_once函数（即单例函数），会导致整体链表无限增长，造成永久性死锁。
分析
根据以上分析，相对应地写了一个简易的死锁Demo，就是在两个单例的初始化调用中直接相互调用。A<->B。也许这个Demo过于简单，大家轻易不会犯。但是如果是A->B->C->A，甚至是更多个模块的相互引用，那又该如何轻易避免呢？
以上的Demo，如果在Xcode模拟器测试环境下，是不会死锁从而导致应用启动被杀。这是因为模拟器不具备守护进程，如果要观察现象，可以输出Log或者直接利用真机进行测试。
有时候，启动耗时是因为占用了太多的CPU资源，CPU占用率高并不是导致启动阶段APP Crash的唯一原因。
反思
虽然这次的问题直接原因是dispatch_once引出的死锁问题，但是个人认为，这却是滥用单例造成的后果。各位可以打开自己公司的app源代码查看一下，究竟存在着多少的单例。
实话实说，单例和全局变量几乎没有任何区别，不仅仅占用了全生命周期的内存，还对解耦造成了巨大的负作用。写起来容易，但是对于整个项目的架构梳理却是有着巨大的影响，因为在不读完整个相关代码的前提下，你压根不知道究竟哪里会触发单例的调用。
因此在这里，谈谈个人认为可以不使用单例的几个方面：
仅仅使用一次的模块，可以不使用单例，可以采用在对应的周期内维护成员实例变量进行替换。
和状态无关的模块，可以采用静态（类）方法直接替换。
可以通过页面跳转进行依赖注入的模块，可以采用依赖注入或者变量传递等方式解决。
当然，的确有一些情况我们仍然需要使用单例。那在这种情况，也请将dispatch_once调用的block内减少尽可能多的任务，最好是仅仅负责初始化，剩下的配置、调用等等在后续进行。