单例模式是GoF模式书中一个完全付费的成员，但最近它似乎被开发人员世界孤立了。我仍然使用了相当多的单线程，特别是对于工厂类，虽然你必须对多线程问题（像任何类一样）小心一点，但我不明白为什么它们如此糟糕。
Stack Overflow似乎特别假设每个人都认为Singleton是邪恶的。为什么？
请用“事实、参考资料或具体专业知识”来支持您的回答
当前回答
因为它们基本上是面向对象的全局变量，所以通常可以用这样的方式设计类，这样就不需要它们了。
其他回答
单例使用静态方法实现。静态方法是做单元测试的人所避免的，因为它们不能被嘲笑或拒绝。这个网站上的大多数人都是单元测试的支持者。避免这种情况的最普遍接受的惯例是使用控制模式反转。
来自谷歌的Misko Hevery就这个话题发表了一些有趣的文章。。。
单身者是病态的骗子。有一个单元测试示例，说明了单身者如何难以找出依赖链并启动或测试应用程序。这是一个相当极端的虐待例子，但他提出的观点仍然有效：
单身者无非是全球国家。全局状态使您的对象可以秘密地获取未在其API中声明的内容，因此，Singleton会将您的API变成病态的骗子。
所有的Singleton都去哪儿了，这表明依赖注入使得向需要实例的构造函数提供实例变得容易，这减轻了第一篇文章中谴责的糟糕的全局Singleton背后的潜在需求。
如果你使用得当且最少，单身汉并不是邪恶的。还有很多其他好的设计模式可以在某一点上替代单例的需求（也可以提供最佳结果）。但是一些程序员不知道这些好模式，在所有情况下都使用单例模式，这使得单例模式对他们来说是有害的。
Singleton是一种模式，可以像任何其他工具一样被使用或滥用。
单例的坏部分通常是用户（或者我应该说单例不适合用于它不适合做的事情）。最大的违规行为是使用单例作为假全局变量。
这是我认为目前为止答案中缺少的：
如果每个进程地址空间需要一个此对象的实例（并且您尽可能确信此需求不会改变），那么应该将其设置为单例。
否则，它不是单例。
这是一个非常奇怪的要求，用户几乎不感兴趣。进程和地址空间隔离是一个实现细节。它们仅在用户希望使用kill或Task Manager停止应用程序时才会对用户产生影响。
除了构建一个缓存系统之外，没有太多的原因可以让您如此确信每个进程只应有一个实例。日志记录系统怎么样？对于每线程或更细粒度的消息可能更好，这样您可以更自动地跟踪消息的来源。应用程序的主窗口如何？这取决于；也许出于某种原因，您希望所有用户的文档都由同一进程管理，在这种情况下，该进程中会有多个“主窗口”。
