答:

在以下情况下使用单例:

您需要在系统中有且只有一个类型的对象

在以下情况下不要使用单例:

你想要节省内存 你想尝试一些新的东西 你想炫耀你知道多少 因为其他人都在这么做(见wikipedia中的cargo cult程序员) 在用户界面小部件中 它应该是一个缓存 在字符串 在会话 我可以玩一整天

如何创建最佳单例:

越小越好。我是一个极简主义者 确保它是线程安全的 确保它永远不为空 确保只创建一次 懒惰还是系统初始化?符合您的要求 有时操作系统或JVM为你创建单例(例如，在Java中每个类定义都是单例) 提供析构函数或以某种方式计算出如何处理资源 使用较少的内存

独生子女的真正缺点是他们打破了继承。你不能派生一个新的类来提供扩展的功能，除非你能访问引用单例的代码。因此，除了Singleton将使您的代码紧密耦合之外(可通过策略模式修复…)又名依赖注入)，它也会阻止你关闭部分代码的修订(共享库)。

因此，即使日志记录器或线程池的示例也是无效的，应该由策略替换。

Anti-Usage:

过度使用单例的一个主要问题是，该模式阻碍了可选实现的简单扩展和交换。类名在任何使用单例的地方都是硬编码的。

当初始化和object时有很多代码正在运行时，单例非常方便。例如，当你使用iBatis设置一个持久化对象时，它必须读取所有的配置，解析映射，确保它是正确的，等等。在开始编写代码之前。

如果每次都这样做，性能会大大降低。在单例中使用它，你只执行一次命中，然后所有后续调用都不必执行它。

关于模式有一点:不要一概而论。当他们有用的时候，当他们失败的时候，他们有所有的情况。

当您必须测试代码时，单例可能会令人讨厌。您通常只能使用类的一个实例，并且可以选择在构造函数中打开一扇门或使用一些方法来重置状态等等。

另一个问题是，Singleton实际上只不过是一个伪装的全局变量。当你的程序有太多的全局共享状态时，事情往往会倒退，我们都知道这一点。

这可能会使依赖追踪更加困难。当所有事情都依赖于你的单例时，就很难改变它，拆分为两个等等。你通常会被它困住。这也妨碍了灵活性。研究一些依赖注入框架来缓解这个问题。

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加载 -日志记录器可以订阅的消息处理程序，您可以向其发送消息。信号处理程序特别要求。