当管理对整个应用程序共享的资源的访问时，应该使用单例，并且可能存在同一个类的多个实例将是破坏性的。确保对共享资源的访问线程安全是这种模式至关重要的一个很好的例子。

当使用单例时，你应该确保你不会意外地隐藏依赖关系。理想情况下，单例对象(就像应用程序中的大多数静态变量一样)在应用程序的初始化代码执行期间设置(c#可执行文件为静态void Main()， java可执行文件为静态void Main())，然后传递给所有其他需要它的实例化类。这有助于维护可测试性。

单例候选人必须满足三个要求:

控制对共享资源的并发访问。 将从系统的多个不同部分请求对资源的访问。 只能有一个对象。

如果你提议的单例只有其中的一两个需求，那么重新设计几乎总是正确的选择。

例如，打印机假脱机程序不太可能从多个位置(打印菜单)调用，因此可以使用互斥来解决并发访问问题。

简单的日志记录器是可能有效的单例的最明显的例子，但这可能会在更复杂的日志记录方案中发生变化。

I use it for an object encapsulating command-line parameters when dealing with pluggable modules. The main program doesn't know what the command-line parameters are for modules that get loaded (and doesn't always even know what modules are being loaded). e.g., main loads A, which doesn't need any parameters itself (so why it should take an extra pointer / reference / whatever, I'm not sure - looks like pollution), then loads modules X, Y, and Z. Two of these, say X and Z, need (or accept) parameters, so they call back to the command-line singleton to tell it what parameters to accept, and the at runtime they call back to find out if the user actually has specified any of them.

在很多方面，处理CGI参数的单例方式与你每次查询只使用一个进程类似(其他mod_*方法不这样做，所以这很糟糕——因此这个参数说你不应该在mod_cgi世界中使用单例，以防你移植到mod_perl或其他世界)。

Singleton类的主要目的是限制创建的实例数量，从而确保对资源的访问控制。

使用单例类不会产生内存空间浪费，因为它限制了实例的创建。因为对象的创建只会发生一次，而不是每次新请求时都创建。

单例类在内部使用互斥量，因此使其线程安全。这就是为什么多线程和数据库应用程序主要使用Java中的Singleton模式进行缓存、日志记录、线程池、配置设置等等

当需要管理共享资源时，可以使用单例。例如打印机假脱机程序。您的应用程序应该只有一个假脱机程序实例，以避免对相同资源的请求冲突。

或者数据库连接或者文件管理器等等。

正如大家所说，共享资源——特别是不能处理并发访问的资源。

我所见过的一个具体例子是Lucene搜索索引写入器。