关于单例滥用导致的crash分析

问题

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,126评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,254评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,445评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,185评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,178评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,970评论 1 284
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,276评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,927评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,400评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,883评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,997评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,646评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,213评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,204评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,423评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,423评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,722评论 2 345

推荐阅读更多精彩内容

  • 在开发中使用单例是最经常不过的事儿了,最常用的就是dispatch_once这个函数,这个函数可以使其参数内的bl...
    ilovehusky阅读 13,175评论 8 52
  • 单例模式例子: https://github.com/XiaoRuiZuo/Singleton 多线程:多线程是为...
    Lee坚武阅读 1,388评论 0 50
  • *面试心声:其实这些题本人都没怎么背,但是在上海 两周半 面了大约10家 收到差不多3个offer,总结起来就是把...
    Dove_iOS阅读 27,124评论 29 470
  • 1.进程 系统中正在运行的应用程序每个进程之间是相互独立的,运行在各自独有且受保护的内存中 2.线程 1.进程是不...
    GSChan阅读 362评论 0 2
  • Lisatang阅读 158评论 0 0