dispatch_once原理,自己使用锁实现单例

原文参考

dispatch_once分析     

在iOS开发中，我们经常使用dispatch_once去定义一个单例，来保证对象的唯一性，不过我们是否去了解过dispatch_once是如何在多线程情况下保证生成对象的唯一性呢？例如，我们经常用下面的代码块生成一个单例。

+ (instancetype)sharedInstance {
    static XXObject *_instance;
    static dispatch_once_t _predicate;
    dispatch_once(&_predicate, ^{
        _instance = [[XXObject alloc] init];
    });
    return _instance;
}

这段代码中涉及到两个关键词，一个是dispatch_once_t，一个是dispatch_once，下面我们逐个分析

dispatch_once_t

在once.h中找到其定义如下： typedef  long  dispatch_once_t;

dispatch_once_t原来是一个长整型！真是让人措手不及…

dispatch_once

void dispatch_once(dispatch_once_t *val, void (^block)(void)){
    struct Block_basic *bb = (void *)block;
    dispatch_once_f(val, block, (void *)bb->Block_invoke);
}

可以看到，在dispatch_once中，生成一个Block_basic指针，指向了block，并把其Block_invoke函数指针传递给了dispatch_once_f
相信大家一定有疑问，Block_basic和Block_invoke是什么东西？很遗憾，源码中找不到，我们可以推测一下：

• Block_basic首先是一个结构体，它定义的指针可以指向void (^block)(void)类型的block
• Block_invoke的字面意思是触发一个block，可以参考以下代码理解

void _dispatch_call_block_and_release(void *block)
{
    void (^b)(void) = block;
    b();
    Block_release(b);
}

接下来分析核心函数dispatch_once_f：

void dispatch_once_f(dispatch_once_t *val, void *ctxt, void (*func)(void *)){
    
    volatile long *vval = val;
    if (dispatch_atomic_cmpxchg(val, 0l, 1l)) {
        func(ctxt); // block真正执行
        dispatch_atomic_barrier();
        *val = ~0l;
    } 
    else 
    {
        do
        {
            _dispatch_hardware_pause();
        } while (*vval != ~0l);
        dispatch_atomic_barrier();
    }
}

 

• 1、dispatch_atomic_cmpxchg，它是一个宏定义，原型为__sync_bool_compare_and_swap((p), (o), (n)) ，这是LockFree给予CAS的一种原子操作机制，原理就是 如果p==o，那么将p设置为n，然后返回true;否则，不做任何处理返回false

• 2、在多线程环境中，如果某一个线程A首次进入dispatch_once_f，*val==0，这个时候直接将其原子操作设为1，然后执行传入dispatch_once_f的block，然后调用dispatch_atomic_barrier，最后将*val的值修改为~0。

• 3、dispatch_atomic_barrier是一种内存屏障，所谓内存屏障，从处理器角度来说，是用来串行化读写操作的，从软件角度来讲，就是用来解决顺序一致性问题的。编译器不是要打乱代码执行顺序吗，处理器不是要乱序执行吗，你插入一个内存屏障，就相当于告诉编译器，屏障前后的指令顺序不能颠倒，告诉处理器，只有等屏障前的指令执行完了，屏障后的指令才能开始执行。所以这里dispatch_atomic_barrier能保证只有在block执行完毕后才能修改*val的值。

• 4、在首个线程A执行block的过程中，如果其它的线程也进入dispatch_once_f，那么这个时候if的原子判断一定是返回false，于是走到了else分支，于是执行了do~while循环，其中调用了_dispatch_hardware_pause，这有助于提高性能和节省CPU耗电，pause就像nop，干的事情就是延迟空等的事情。直到首个线程已经将block执行完毕且将*val修改为~0，调用dispatch_atomic_barrier后退出。这么看来其它的线程是无法执行block的，这就保证了在dispatch_once_f的block的执行的唯一性，生成的单例也是唯一的。

dispatch_once死锁     

参考案例 ： https://www.jianshu.com/p/58f5fb01ae4f

上面说了这么多，是不是说使用dispatch_once写单例就可以高枕无忧了呢？
实际上并非如此，不正当地使用dispatch_once可能会造成死锁：

• 死锁方式1：
  1、某线程T1()调用单例A，且为应用生命周期内首次调用，需要使用dispatch_once(&token, block())初始化单例。
  2、上述block()中的某个函数调用了dispatch_sync_safe，同步在T2线程执行代码
  3、T2线程正在执行的某个函数需要调用到单例A，将会再次调用dispatch_once。
  4、这样T1线程在等block执行完毕，它在等待T2线程执行完毕，而T2线程在等待T1线程的dispatch_once执行完毕，造成了相互等待，故而死锁

• 死锁方式2：
  1、某线程T1()调用单例A，且为应用生命周期内首次调用，需要使用dispatch_once(&token, block())初始化单例；
  2、block中可能掉用到了B流程，B流程又调用了C流程，C流程可能调用到了单例A，将会再次调用dispatch_once；
  3、这样又造成了相互等待。

所以在使用写单例时要注意：

• 1、初始化要尽量简单，不要太复杂；
• 2、尽量能保持自给自足，减少对别的模块或者类的依赖；
• 3、单例尽量考虑使用场景，不要随意实现单例，否则这些单例一旦初始化就会一直占着资源不能释放，造成大量的资源浪费。

 

dispatch_once也可以通过锁来实现，使用dispatch_semaphore,NSLock，@synchronized 这些都可以实现，但是效率没有dispatch_once高。实测也是可以的。

// 方式1，使用synchronized最简单
+ (instancetype)synchronizedManager {

    static Person * m = nil;
    @synchronized (self) {
        
        if (m == nil) {
            // 模拟耗时操作,给其他线程进入提供机会
            sleep(3);
            m = [[self alloc] init];
            NSLog(@"synchronizedManager 只执行一次是对的");
        }
        
    }
    return m;
    
}
// 方式2，使用dispatch_semaphore,需要多一些操作,NSLock同理
static dispatch_semaphore_t sem = nil;
+ (void)initialize {
    if (sem == nil) {
        sem = dispatch_semaphore_create(1);
    }
}
+ (instancetype)semaphoreManager {
    
    dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);
    static Person * m = nil;
    if (m == nil) {
        // 模拟耗时操作,给其他线程进入提供机会
        sleep(3);
        m = [[self alloc] init];
        NSLog(@"semaphoreManager 只执行一次是对的");
    }
    dispatch_semaphore_signal(sem);
    return m;
    
}