一些代码势利者看不起他们，认为他们只是一个荣耀的全球人。就像许多人讨厌goto语句一样，也有其他人讨厌使用全局的想法。我见过几位开发人员为了避免全局性而竭尽全力，因为他们认为使用全局性是失败的承认。奇怪但真实。

在实践中，Singleton模式只是一种编程技术，它是概念工具包的有用部分。有时你可能会发现它是理想的解决方案，所以使用它。但使用它只是为了吹嘘使用设计模式，就像拒绝使用它一样愚蠢，因为它只是一个全球性的。

我对单身汉如何糟糕的回答总是，“他们很难做对”。语言的许多基本组件都是单体（类、函数、名称空间甚至运算符），计算的其他方面（本地主机、默认路由、虚拟文件系统等）也是如此，这并非偶然。虽然它们会时不时地带来麻烦和挫折，但也能让很多事情变得更好。

我看到的两个最大的错误是：将其视为一个全球性的问题&未能定义Singleton闭包。

每个人都把辛格尔顿说成是全球性的，因为他们基本上是全球性的。然而，在一个全球性的世界中，很多（不幸的是，并非所有）糟糕的地方并不是来自于全球化，而是来自于你如何使用它。辛格尔顿也是如此。事实上，“单个实例”并不意味着“全局可访问”。它更多的是一种自然的副产品，而且考虑到我们所知道的所有负面影响，我们不应该急于利用全球可访问性。一旦程序员看到Singleton，他们似乎总是通过它的实例方法直接访问它。相反，您应该像导航任何其他对象一样导航到它。大多数代码甚至不应该意识到它正在处理Singleton（松耦合，对吗？）。如果只有一小部分代码像访问全局对象一样访问该对象，那么很多危害都会消除。我建议通过限制对实例函数的访问来实施它。

辛格尔顿的背景也非常重要。Singleton的定义特征是“只有一个”，但事实是它在某种上下文/名称空间中是“唯一的”。它们通常是以下之一：每个线程、进程、IP地址或集群一个，但也可以是每个处理器、机器、语言名称空间/类加载器/任何东西、子网、Internet等。

另一个不太常见的错误是忽视单身汉的生活方式。仅仅因为只有一个，并不意味着Singleton是某种无所不能的“一直都是，永远都会是”，也不是普遍可取的（没有开始和结束的对象违反了代码中所有有用的假设，只应在最绝望的情况下使用。

如果你避免了这些错误，辛格尔顿仍然可以成为一名医院，但它已经做好了准备，可以看到许多最严重的问题得到了显著的缓解。想象一个Java Singleton，它被明确定义为每个类加载器一次（这意味着它需要线程安全策略），具有定义的创建和销毁方法，以及指定何时和如何调用它们的生命周期，其“实例”方法具有包保护，因此通常可以通过其他非全局对象访问。仍然是潜在的麻烦来源，但麻烦肯定要少得多。

可悲的是，他们没有教好如何做单身汉的例子。我们教坏的例子，让程序员暂时不用它们，然后告诉他们它们是坏的设计模式。

还有一件关于单身汉的事，还没有人说过。

在大多数情况下，“singletony”是某个类的实现细节，而不是其接口的特征。控制容器的反转可能会对类用户隐藏此特性；您只需要将类标记为singleton（例如，在Java中使用@singleton注释），就可以了；IoCC将完成剩下的工作。您不需要提供对单例实例的全局访问，因为访问已经由IoCC管理。因此，IoC Singleton没有任何问题。

与IoC Singleton相反的GoF Singleton应该通过getInstance（）方法在接口中暴露“singletony”，因此他们会受到上面所说的一切影响。

参见Wikipedia Singleton_pattern

一些人还认为它是一种反模式，他们认为它被过度使用，在实际上不需要类的唯一实例的情况下引入了不必要的限制。[1][2][3][4]

参考文献（仅文章中的相关参考文献）

^亚历克斯·米勒。我讨厌的模式#1：辛格尔顿，2007年7月^Scott Densmore。为什么单身汉是邪恶的，2004年5月^史蒂夫·耶格。单身汉被认为愚蠢，2004年9月^J.B.Rainsberger，IBM。2001年7月，明智地使用你的单身

太多人将非线程安全的对象放在单例模式中。尽管DataContext不是线程安全的，纯粹是一个工作单元对象，但我已经看到了DataContext（LINQ to SQL）以单例模式完成的示例。

从纯粹主义的观点来看，单身汉是不好的。

从实践的角度来看，单例是开发时间与复杂性的权衡。

如果你知道你的应用程序不会有太大的变化，那么它们很好用。只要知道，如果您的需求以意外的方式发生变化（在大多数情况下这是很正常的），您可能需要重构。

单体有时也会使单元测试复杂化。