Meyers单例模式在大多数情况下工作得足够好，在某些情况下，寻找更好的模式并不一定值得。只要构造函数永远不会抛出，并且单例对象之间没有依赖关系。

单例对象是全局可访问对象(从现在开始是GAO)的实现，尽管并非所有的GAO都是单例对象。

日志记录器本身不应该是单例的，但是理想情况下，记录日志的方法应该是全局可访问的，以便将日志消息的生成位置与日志记录的位置或方式分离。

延迟加载/延迟计算是一个不同的概念，单例通常也实现了这一点。它自身也有很多问题，尤其是线程安全问题，如果出现异常而失败，那么在当时看来是个好主意，结果却并不是那么好。(有点像字符串中的COW实现)。

考虑到这一点，goa可以像这样初始化:

namespace {

T1 * pt1 = NULL;
T2 * pt2 = NULL;
T3 * pt3 = NULL;
T4 * pt4 = NULL;

}

int main( int argc, char* argv[])
{
   T1 t1(args1);
   T2 t2(args2);
   T3 t3(args3);
   T4 t4(args4);

   pt1 = &t1;
   pt2 = &t2;
   pt3 = &t3;
   pt4 = &t4;

   dostuff();

}

T1& getT1()
{
   return *pt1;
}

T2& getT2()
{
   return *pt2;
}

T3& getT3()
{
  return *pt3;
}

T4& getT4()
{
  return *pt4;
}

它不需要那么粗糙地完成，显然，在包含对象的加载库中，您可能需要一些其他机制来管理它们的生命周期。(将它们放在加载库时获得的对象中)。

至于我什么时候使用单例对象?我用它们做了两件事 -一个单例表，指示哪些库已经被dlopen加载 -日志记录器可以订阅的消息处理程序，您可以向其发送消息。信号处理程序特别要求。

第一个例子不是线程安全的——如果两个线程同时调用getInstance，这个静态将是一个PITA。某种形式的互斥会有所帮助。

单例对象的问题不在于它们的实现。而是它们合并了两个不同的概念，这两个概念显然都不可取。

1)单例提供了对对象的全局访问机制。尽管在没有定义良好的初始化顺序的语言中，它们可能更线程安全或更可靠，但这种用法在道义上仍然相当于全局变量。它是一个用一些笨拙的语法修饰的全局变量(比如说，foo::get_instance()而不是g_foo)，但它具有完全相同的目的(在整个程序中可访问的单个对象)，并且具有完全相同的缺点。

2)单例防止一个类的多个实例化。据我所知，这种特性很少被添加到类中。这通常是一个更有语境的东西;很多被认为是独一无二的东西实际上只是碰巧是独一无二的。在我看来，更合适的解决方案是只创建一个实例——直到您意识到需要多个实例为止。

单例基本上让你在语言中拥有复杂的全局状态，否则就很难或不可能拥有复杂的全局变量。

Java特别使用单例变量作为全局变量的替代品，因为所有内容都必须包含在类中。最接近全局变量的是公共静态变量，它们可以像导入静态的全局变量一样使用

c++确实有全局变量，但是调用全局类变量的构造函数的顺序未定义。因此，单例可以让您推迟全局变量的创建，直到第一次需要该变量。

Python和Ruby等语言很少使用单例，因为您可以在模块中使用全局变量。

那么什么时候使用单例对象是好的/坏的呢?差不多就是什么时候使用全局变量是好是坏。

在桌面应用程序中(我知道，只有我们这些恐龙才会写这些!)，它们对于获得相对不变的全局应用程序设置是必不可少的——用户语言，帮助文件的路径，用户首选项等等，否则就必须传播到每个类和每个对话框中。

编辑-当然这些应该是只读的!

如果你是创建单例对象并使用它的人，不要将它设置为单例对象(这没有意义，因为你可以控制对象的奇点而不将其设置为单例对象)，但如果你是一个库的开发人员，并且你只想向你的用户提供一个对象，这是有意义的(在这种情况下，你是创建单例对象的人，但你不是用户)。

单例对象所以使用它们作为对象,很多人访问单例直接通过调用方法返回它,但这是有害的因为你使你的代码知道对象是单身,我喜欢用单例对象,我通过构造函数传递它们,使用它们作为普通对象,通过这种方式,你的代码不知道是否这些对象是单例对象,这让依赖关系更加明确,它有助于重构……