『ios』dispatch_once死锁和滥用单例导致的问题

Posted 2023-05-08

参考技术A

在学习dispatch_once原理过程中，发现了之前因为信号量引起的卡住主线程的问题所在。
所以，了解原理，绝对是提高自己的必备条件。
我们带着两个问题去看
1.单例为什么会造成死锁。
2.滥用单例为什么会导致内存不断增加。
如果对dispatch_once的基础原理还不了解，可以看上一篇文章。

带着问题，我们还是先看dispatch_once_f这个函数。

首先我们先来认识几个对象.

要对dow.dow_next有个印象，因为后面会用。

**1.dispatch_once_f(dispatch_once_t val, void ctxt, dispatch_function_t func)传入了三个参数ctxt是外部传入的block的指针，func是block里具体执行的函数。
2. dispatch_atomic_cmpxchg 是原子交换函数，dispatch_atomic_cmpxchg(vval, NULL, &dow)也就是吧vval的值赋值给&dow.
3. _dispatch_client_callout(ctxt, func);根据ctxt找到block，并执行block中的函数。
4. dispatch_atomic_maximally_synchronizing_barrier函数的作用，是可以让其他线程来读取到未初始化的对象，从而可以使这些线程进入dispatch_once_f的另外一个分支（else分支）进行等待。
5.tmp = dispatch_atomic_xchg(vval, DISPATCH_ONCE_DONE);使其为DISPATCH_ONCE_DONE，即“完成”。
6.然后比较 tmp和&dow的值，如果这两个相等，分支结束。
7.如果 tmp和&dow的值不相等，为什么会不相等呢。因为在block执行过程中，会有其他线程进入到本函数，我们可以看else后面的内容，会形成一个信号量链表，（vval指向值变为信号量链的头部，链表的尾部为&dow），在这时候，进入分支1的while循环中，因为我们前面，struct _dispatch_once_waiter_s dow = NULL, 0 ; ，dow.dow_next为null，所以需要一直等待，等待temp.dow_next有值才可以进行后面的操作。然后分支1就会进行等待分支2的进行，只有当分支2的dow_dow_next = tmp被执行了，才可以继续往后面执行。

8.我们仔细看下分支2的操作。
创建了一个信号量，并把值赋值给dow.dow_sema.

然后进入了一个for循环中，如果vval的值已经为DISPATCH_ONCE_DONE，则直接break。
如果vval的值不为DISPATCH_ONCE_DONE，则把vval赋值给&dow.此时val.dow_next还是为null，把dow.dow_next = tmp来增加链表的节点，解决了分支1中while进行等待的问题。

然后等待在信号量上，当block执行分支1完成并遍历链表来signal时，唤醒、释放信号量，然后一切就完成了。

分支1的while循环，需要等待分支2的 dow.dow_next = tmp;赋值，然后，分支2的 _dispatch_thread_semaphore_wait(dow.dow_sema);需要等待分支1的_dispatch_thread_semaphore_signal(sema);。

总结下上面的问题。
dispatch_once实际上内部会构建一个俩表来维护，如果在block完成之前，有其它的调用者进来，则会把这些调用者放到一个waiter链表中。
waiter链表中的每个调用者会等待一个信号量(dow.dow_sema)。在block执行完了后，除了将onceToken置为DISPATCH_ONCE_DONE外，还会去遍历waiter链中的所有waiter，抛出相应的信号量，以告知waiter们调用已经结束了
上面的两个问题。

死锁如何形成？
两个类相互调用其单例方法时，调用者TestA作为一个waiter，在等待TestB中的block完成，而TestB中block的完成依赖于TestA中单例函数的block的执行完成，而TestA中的block想要完成还需要TestB中的block完成……两个人都在相互等待对方的完成，这就成了一个死锁。

滥用单例的为什么会死锁。
如果在dispatch_once函数的block块执行期间，循环进入自己的dispatch_once函数，会造成链表一直增长，同样也会造成死锁。（这里只是简单的A->B->A->B->A这样的循环，也可以是A->A->A这样的更加直接的循环.
如果在block执行期间，多次进入调用同类的dispatch_once函数（即单例函数），会导致整体链表无限增长，造成永久性死锁
我觉得这也就是之前，坐那个直播中，用信号量来控制时，为什么会卡主，因为我用单例封装的信号量，然后单例循环调用，发生了死锁。

2021.8.10 补充一下死锁的demo

通过下面的报错位置，在对应着源码，应该可以看出问题所在。

（一二三）基于GCD的dispatch_once实现单例设计

要实现单例，关键是要保证类的alloc和init仅仅被调用一次。而且被自身强引用防止释放。

近日读唐巧先生的《iOS开发进阶》。受益匪浅，通过GCD实现单例就是收获之中的一个，以下把这种方法与大家分享。

在GCD中，有一个函数dispatch_once，能够实现代码段的一次性运行，和static修饰的变量赋值的一次性一样。我们结合static和dispatch_once，就能够简单的实现单例。

以下的代码实现了SomeClass单例：

#import <Foundation/Foundation.h>

@interface SomeClass : NSObject

+ (SomeClass *)sharedInstance;

@end

#import "SomeClass.h"

@implementation SomeClass

+ (SomeClass *)sharedInstance{
    
    static id sharedInstance = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        sharedInstance = [[self alloc] init];
    });
    
    return sharedInstance;
    
}

@end

以下解释一下这段代码。

第一句新建一个sharedInstance静态强指针，是为了指向创建好的单例，防止其释放，仅仅有第一次进入的时候指针被赋值为nil。

一定注意dispatch_once_t变量必须是静态，它的值用于推断是否已经运行一次。

第二句和dispatch_once是固定使用方法，这样能够实现block内的代码一次性运行。也就是说仅仅有第一次调用这种方法时才会实例化类。之后都是返回指针指向的值。

最后返回指针，就相当于拿到了单例。

对单例的执行结果进行验证：

我们多次获取单例对象而且打印地址，能够发现地址是一样的。

#import "ViewController.h"
#import "SomeClass.h"

@interface ViewController ()

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    SomeClass *sc1 = [SomeClass sharedInstance];
    SomeClass *sc2 = [SomeClass sharedInstance];
    SomeClass *sc3 = [SomeClass sharedInstance];
    NSLog(@"%p %p %p",sc1,sc2,sc3);
    
}

@end

2015-08-17 20:59:22.139 基于GCD实现单例[2785:31918] 0x7fb40af11b90 0x7fb40af11b90 0x7fb40af11b90

通过这样的方式，简单高效的实现了单例，值得使用。