双重检查锁优化以在 Swift 中实现线程安全的延迟加载

Question

我已经在一个类中实现了我认为的双重检查锁定，以实现线程安全的延迟加载。

以防万一您想知道，这是我目前正在处理的DI library。

我说的代码是the following:

final class Builder<I> {

   private let body: () -> I

   private var instance: I?
   private let instanceLocker = NSLock()

   private var isSet = false
   private let isSetDispatchQueue = DispatchQueue(label: "\(Builder.self)", attributes: .concurrent)

   init(body: @escaping () -> I) {
       self.body = body
   }

   private var syncIsSet: Bool {
       set {
          isSetDispatchQueue.async(flags: .barrier) {
             self.isSet = newValue
          }
       }
       get {
          var isSet = false
          isSetDispatchQueue.sync {
              isSet = self.isSet
          }
          return isSet
       }
   }

   var value: I {

       if syncIsSet {
           return instance! // should never fail
       }

       instanceLocker.lock()

       if syncIsSet {
           instanceLocker.unlock()
           return instance! // should never fail
       }

       let instance = body()
       self.instance = instance

       syncIsSet = true
       instanceLocker.unlock()

       return instance
    }
}

逻辑是允许并发读取isSet，因此对instance的访问可以从不同的线程并行运行。为了避免竞争条件（这是我不能 100% 确定的部分），我有两个障碍。一个用于设置isSet，一个用于设置instance。诀窍是仅在 isSet 设置为 true 后才解锁后者，因此等待 instanceLocker 解锁的线程会在 isSet 上第二次锁定，同时它被异步写入并发调度队列。

我认为我离最终解决方案很近了，但由于我不是分布式系统专家，所以我想确定一下。

另外，使用调度队列不是我的第一选择，因为它让我觉得阅读 isSet 效率不高，但同样，我不是专家。

所以我的两个问题是：

• 这是 100% 线程安全的吗？如果不是，为什么？
• 有没有更高效的 在 Swift 中如何做到这一点？

Answer 1

IMO，这里的正确工具是os_unfair_lock。双重检查锁定的目的是避免使用完整的内核锁定。 os_unfair_lock 在无争议的情况下提供了这一点。它的“不公平”部分是它没有承诺等待线程。如果一个线程解锁，则允许重新锁定而另一个等待线程没有机会（因此可能会饿死）。在使用非常小的临界区的实践中，这是不相关的（在这种情况下，您只是针对 nil 检查局部变量）。它是一个比调度到队列更低级别的原语，它非常快，但不如不公平锁快，因为它依赖于不公平锁等原语。

final class Builder<I> {

    private let body: () -> I
    private var lock = os_unfair_lock()

    init(body: @escaping () -> I) {
        self.body = body
    }

    private var _value: I!
    var value: I {
        os_unfair_lock_lock(&lock)
        if _value == nil {
            _value = body()
        }
        os_unfair_lock_unlock(&lock)

        return _value
    }
}

请注意，您在 syncIsSet 上进行同步是正确的。如果您将其视为原语（这在其他双重检查同步中很常见），那么您将依赖 Swift 不承诺的东西（编写 Bool 的原子性和它实际上会检查 boolean两次，因为没有volatile)。鉴于您正在进行同步，比较是在 os_unfair_lock 和调度到队列之间。

也就是说，根据我的经验，这种懒惰在移动应用程序中几乎总是没有根据的。如果变量非常昂贵但可能从未访问过，它实际上只会节省您的时间。有时在大规模并行系统中，能够移动初始化是值得的，但移动应用程序运行在相当有限数量的内核上，因此通常没有一些额外的内核可以将其分流。除非您已经发现在实时系统中使用您的框架时这是一个重大问题，否则我通常不会追求这一点。如果您有，那么我建议在显示此问题的实际用法中针对 os_unfair_lock 分析您的方法。我希望os_unfair_lock 获胜。