单例线程安全类

Question

我在多线程环境中做的工作很少。所以，我需要知道below类的getInstance函数是否是线程安全的。这是单例类:

//Singleton class
class S {
  // intentionally avoided pointer
  static S singleObject;

   // Private constructor   
   s ();
   s (S &);
   s& operator= (const s&);
public:
  // return reference of static object
  s& getInstance ()
  {
    return singleObject;
  }

  /* Normally with static pointer instance, getInstnace look like as
   s& getInstace ()
   {
      // trying to avoid multiple copies of singleObject
      lock_mutex ()

       if (singleObject == null)
          singleObjecct = new S();

      unlock_mutex ();

      return *singleObject;
    }
  */
};

S S::singleObject;

在getInstance函数（未注释）中，返回静态对象的引用。它需要线程安全机制吗？

在第二个getInstance（注释）中，如果singleObject为null，我们就创建对象。所以，它需要锁定机制，需要同步，对吧？

Answer 1

除非您将 getInstance 声明为静态，否则您将无法调用它。这个错误几乎传播到所有回复。除此之外，我不能为所有答案添加更好的东西。

Answer 2

在 C 11 中，您可以将静态实例放在静态函数中：

class S
{
    private:
        S();
        S(S const&);
        S& operator=(S const&);

    public:
        static S& getInstance ()
        {
            static S singleObject;
            return singleObject;
        }
};

根据本标准第6.7.4段：

所有具有静态存储持续时间(3.7.1)或线程存储持续时间(3.7.2)的块范围变量的零初始化(8.5)在任何其他初始化发生之前执行。具有静态存储持续时间的块范围实体的常量初始化(3.6.2)在第一次进入其块之前执行(如果适用)。在允许实现在名称空间范围内静态初始化具有静态或线程存储持续时间的变量的相同条件下，允许实现使用静态或线程存储持续时间执行其他块范围变量的早期初始化(3.6.2)。否则，这样的变量在控制第一次通过其声明时被初始化；这种变量在其初始化完成时被认为是已初始化的。如果初始化通过引发异常退出，则初始化未完成，因此下次控件进入声明时将再次尝试初始化。如果控制在变量初始化的同时进入声明，则并发执行将等待初始化完成。如果在初始化变量时，控制递归地重新进入声明，则行为是未定义的。

Answer 3

在getInstance函数（未注释）中，返回静态对象的引用。它需要线程安全机制吗？

只要不在< code>main函数的生存期之外访问它，或者在其他线程可能进行非同步访问时修改它，那么从任何线程访问它都是安全的。

如果您在< code>main开始之前或结束之后进行访问(例如，从另一个静态对象的构造函数或析构函数中访问)，那么就存在这样一种危险，即在那一点上它还没有被初始化，或者已经被销毁。这就是“懒惰初始化”的动机，比如你的第二个版本。

在第二个getInstance（注释）中，如果singleObject为null，我们就创建对象。所以，它需要锁定机制，需要同步，对吧？

是的，这需要一个锁定机制。对于支持 C 11（或类似）线程模型的编译器，像这样获取惰性初始化的更简单方法是使用函数静态变量，该变量将在首次进入范围时以线程安全的方式初始化：

S& getInstance ()
{
    static S singleObject;
    return singleObject;
}

这也将避免您的版本的内存泄漏，但是引入了一个危险，即它可能在其他静态对象之前被销毁；因此，从静态对象的析构函数访问是不安全的。

一般来说，C中的静态对象是这种死亡陷阱的雷区（无论您是否尝试将它们包装成某种单例反模式），最好避免。