来自谷歌的Misko Hevery就这个话题发表了一些有趣的文章。。。

单身者是病态的骗子。有一个单元测试示例，说明了单身者如何难以找出依赖链并启动或测试应用程序。这是一个相当极端的虐待例子，但他提出的观点仍然有效：

单身者无非是全球国家。全局状态使您的对象可以秘密地获取未在其API中声明的内容，因此，Singleton会将您的API变成病态的骗子。

所有的Singleton都去哪儿了，这表明依赖注入使得向需要实例的构造函数提供实例变得容易，这减轻了第一篇文章中谴责的糟糕的全局Singleton背后的潜在需求。

它模糊了关注点的分离。

假设您有一个单例，您可以从类中的任何位置调用此实例。您的类不再像它应该的那样纯粹。您的类现在将不再对其成员及其显式接收的成员进行操作。这会造成混乱，因为类的用户不知道该类所需的足够信息是什么。封装的整个思想是向用户隐藏方法的方式，但如果在方法内部使用了单例，则必须知道单例的状态才能正确使用该方法。这是反OOP。

摘自Brian Button：

它们通常被用作全局实例，为什么如此糟糕？因为您将应用程序的依赖项隐藏在代码中，而不是通过接口公开它们。让一些东西全球化以避免传播是一种代码气味。他们违反了单一责任原则：因为他们控制自己的创作和生命周期。它们固有地导致代码紧密耦合。这使得在许多情况下，在测试中伪造它们相当困难。它们在应用程序的整个生命周期中携带状态。另一个对测试的打击，因为您可能会遇到一种需要订购测试的情况，这对于单元测试来说是一个很大的禁忌。为什么？因为每个单元测试都应该彼此独立。

如果你使用得当且最少，单身汉并不是邪恶的。还有很多其他好的设计模式可以在某一点上替代单例的需求（也可以提供最佳结果）。但是一些程序员不知道这些好模式，在所有情况下都使用单例模式，这使得单例模式对他们来说是有害的。

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

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

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

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

单身者解决了一个（而且只有一个）问题。

资源争夺。

如果你有一些资源

（1） 只能有一个实例，并且

（2） 您需要管理单个实例，

你需要一个单身汉。

例子不多。日志文件是最大的文件。您不想只放弃一个日志文件。您希望正确刷新、同步和关闭它。这是必须管理的单个共享资源的示例。

你很少需要单身汉。他们之所以不好，是因为他们觉得自己是一个全球性的人，而且他们是GoF设计模式书的全额付费成员。

当你认为你需要一个全局，你可能犯了一个可怕的设计错误。