Mike Ash Singleton：放置@synchronized

Question

我在迈克·阿什（Mike Ash）的“单身人士的护理和喂养”中看到了这一点，并对他的评论感到有点困惑：

不过，这段代码有点慢。 获取锁有点昂贵。 事实却让事情变得更加痛苦 绝大多数时候， 锁是没有意义的。锁是 仅当 foo 为零时才需要，即 基本上只发生一次。之后 单例初始化时，需要 锁不见了，但锁本身 仍然存在。

+(id)sharedFoo {
    static Foo *foo = nil;
    @synchronized([Foo class]) {
        if(!foo) foo = [[self alloc] init];
    }
    return foo;
}

我的问题是，毫无疑问这是有充分理由的，但为什么你不能编写（见下文）来将锁限制在 foo 为零时？

+(id)sharedFoo {
    static Foo *foo = nil;
    if(!foo) {
        @synchronized([Foo class]) {
            foo = [[self alloc] init];
        }
    }
    return foo;
}

干杯加里

Answer 1

因为这样测试就会受到竞争条件的影响。两个不同的线程可能会独立测试 foo 是否为 nil，然后（依次）创建单独的实例。在您的修改版本中，当一个线程执行测试而另一个线程仍在 +[Foo alloc] 或 -[Foo init] 内但尚未设置时，可能会发生这种情况foo。

顺便说一句，我根本不会那样做。查看 dispatch_once() 函数，它可以让您保证一个块在应用程序的生命周期内只执行一次（假设您在目标平台上有 GCD）。

Answer 2

这称为双重检查锁定“优化”。正如各地记录的那样，这是不安全的。即使它没有被编译器优化击败，它也会以现代机器上内存的工作方式被击败，除非您使用某种栅栏/屏障。

Mike Ash 还展示了使用易失性和OSMemoryBarrier();的正确解决方案。

问题是，当一个线程执行 foo = [[self alloc] init]; 时，无法保证当另一线程看到 foo != 0 时所有内存写入都会执行by init 也是可见的。

另请参阅 DCL 和 C++ 和 DCL 和 java 了解更多详细信息。

Answer 3

在您的版本中，对 !foo 的检查可能同时在多个线程上进行，允许两个线程跳转到 alloc 块，一个等待另一个线程完成在分配另一个实例之前。

Answer 4

您可以通过仅在 foo==nil 时获取锁定来进行优化，但之后您需要再次测试（在 @synchronized 内）以防止竞争条件。

+ (id)sharedFoo {
    static Foo *foo = nil;
    if(!foo) {
        @synchronized([Foo class]) {
            if (!foo)  // test again, in case 2 threads doing this at once
                foo = [[self alloc] init];
        }
    }
    return foo;
}

Answer 5

如果您有中央调度，最好的方法

+ (MySingleton*) instance {
 static dispatch_once_t _singletonPredicate;
 static MySingleton *_singleton = nil;

 dispatch_once(&_singletonPredicate, ^{
    _singleton = [[super allocWithZone:nil] init];
 });

 return _singleton
 }
+ (id) allocWithZone:(NSZone *)zone {
  return [self instance];
 }