问题
最近排查一个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的认知相悖)
从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内减少尽可能多的任务,最好是仅仅负责初始化,剩下的配置、调用等等在后续进行。