大多数人在试图让自己对使用全局变量感觉良好时使用单例变量。有合法的使用，但大多数时候，当人们使用它们时，只能有一个实例的事实，与它是全局可访问的事实相比，只是一个微不足道的事实。

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

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

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

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

Alexandrescu的现代c++设计有一个线程安全的、可继承的泛型单例。

对于我的2p价值，我认为为你的单例对象定义生命周期是很重要的(当绝对有必要使用它们时)。我通常不让静态的get()函数实例化任何东西，把设置和销毁留给主应用程序的某个专用部分。这有助于突出单例程序之间的依赖关系——但是，正如上面强调的，如果可能的话最好避免它们。

我认为这是c#最健壮的版本:

using System;
using System.Collections;
using System.Threading;

namespace DoFactory.GangOfFour.Singleton.RealWorld
{

  // MainApp test application

  class MainApp
  {
    static void Main()
    {
      LoadBalancer b1 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b2 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b3 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b4 = LoadBalancer.GetLoadBalancer();

      // Same instance?
      if (b1 == b2 && b2 == b3 && b3 == b4)
      {
        Console.WriteLine("Same instance\n");
      }

      // All are the same instance -- use b1 arbitrarily
      // Load balance 15 server requests
      for (int i = 0; i < 15; i++)
      {
        Console.WriteLine(b1.Server);
      }

      // Wait for user
      Console.Read();    
    }
  }

  // "Singleton"

  class LoadBalancer
  {
    private static LoadBalancer instance;
    private ArrayList servers = new ArrayList();

    private Random random = new Random();

    // Lock synchronization object
    private static object syncLock = new object();

    // Constructor (protected)
    protected LoadBalancer()
    {
      // List of available servers
      servers.Add("ServerI");
      servers.Add("ServerII");
      servers.Add("ServerIII");
      servers.Add("ServerIV");
      servers.Add("ServerV");
    }

    public static LoadBalancer GetLoadBalancer()
    {
      // Support multithreaded applications through
      // 'Double checked locking' pattern which (once
      // the instance exists) avoids locking each
      // time the method is invoked
      if (instance == null)
      {
        lock (syncLock)
        {
          if (instance == null)
          {
            instance = new LoadBalancer();
          }
        }
      }

      return instance;
    }

    // Simple, but effective random load balancer

    public string Server
    {
      get
      {
        int r = random.Next(servers.Count);
        return servers[r].ToString();
      }
    }
  }
}

下面是. net优化版:

using System;
using System.Collections;

namespace DoFactory.GangOfFour.Singleton.NETOptimized
{

  // MainApp test application

  class MainApp
  {

    static void Main()
    {
      LoadBalancer b1 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b2 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b3 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b4 = LoadBalancer.GetLoadBalancer();

      // Confirm these are the same instance
      if (b1 == b2 && b2 == b3 && b3 == b4)
      {
        Console.WriteLine("Same instance\n");
      }

      // All are the same instance -- use b1 arbitrarily
      // Load balance 15 requests for a server
      for (int i = 0; i < 15; i++)
      {
        Console.WriteLine(b1.Server);
      }

      // Wait for user
      Console.Read();    
    }
  }

  // Singleton

  sealed class LoadBalancer
  {
    // Static members are lazily initialized.
    // .NET guarantees thread safety for static initialization
    private static readonly LoadBalancer instance =
      new LoadBalancer();

    private ArrayList servers = new ArrayList();
    private Random random = new Random();

    // Note: constructor is private.
    private LoadBalancer()
    {
      // List of available servers
      servers.Add("ServerI");
      servers.Add("ServerII");
      servers.Add("ServerIII");
      servers.Add("ServerIV");
      servers.Add("ServerV");
    }

    public static LoadBalancer GetLoadBalancer()
    {
      return instance;
    }

    // Simple, but effective load balancer
    public string Server
    {
      get
      {
        int r = random.Next(servers.Count);
        return servers[r].ToString();
      }
    }
  }
}

你可以在dotfactory.com上找到这个模式。

单身让你有能力在一个职业中结合两种坏特性。这在任何方面都是错误的。

单例可以给你:

对对象的全局访问，以及 这种类型只能创建一个对象的保证

第一点很简单。全局变量通常不好。除非真的需要，否则永远不要让对象具有全局可访问性。

第二点可能听起来很有道理，但让我们想想。上次你**不小心*创建了一个新对象而不是引用一个现有对象是什么时候?因为它被标记为c++，所以让我们使用该语言中的一个示例。你经常不小心写东西吗

std::ostream os;
os << "hello world\n";

当你打算写信的时候

std::cout << "hello world\n";

当然不是。我们不需要防范这种错误，因为这种错误根本不会发生。如果确实如此，正确的反应是回家睡12-20个小时，希望你能感觉好点。

如果只需要一个对象，只需创建一个实例。如果一个对象应该是全局可访问的，则将其设置为全局。但这并不意味着不可能创建它的其他实例。

“只有一个实例是可能的”约束并不能真正保护我们免受可能的错误。但这确实使我们的代码很难重构和维护。因为我们经常会发现我们需要不止一个实例。我们确实有不止一个数据库，不止一个配置对象，我们确实需要几个记录器。举一个常见的例子，我们的单元测试可能希望能够在每次测试中创建和重新创建这些对象。

So a singleton should be used if and only if, we need both the traits it offers: If we need global access (which is rare, because globals are generally discouraged) and we need to prevent anyone from ever creating more than one instance of a class (which sounds to me like a design issue). The only reason I can see for this is if creating two instances would corrupt our application state - probably because the class contains a number of static members or similar silliness. In which case the obvious answer is to fix that class. It shouldn't depend on being the only instance.

如果你需要全局访问一个对象，把它设置为全局的，比如std::cout。但是不要限制可以创建的实例的数量。

如果您确实需要将一个类的实例数量限制为一个，并且无法安全地处理创建第二个实例，那么就强制执行。但不要让它在全球范围内都可以使用。

如果你确实需要这两个特性，那么1)让它成为单例，2)让我知道你需要它做什么，因为我很难想象这样的情况。

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