也许是一个带有代码的示例。

在这里，ConcreteRegistry是一个纸牌游戏中的单例，它允许行为沿着包树向上访问游戏的少数核心接口(即模型、视图、控制器、环境等的外观):

http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs40.html

Ed.

只读单例存储一些全局状态(用户语言、帮助文件路径、应用程序路径)是合理的。使用单例控制业务逻辑时要小心——单例几乎总是以多例告终

读取应该只在启动时读取的配置文件，并将它们封装在Singleton中。

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或其他世界)。

当您想要确保一个类将有一个实例，并且该实例将有一个全局访问点时，您可以使用单例设计模式。

假设您有一个应用程序，它需要数据库来处理CRUD操作。理想情况下，您应该使用与数据库相同的连接对象来访问数据库并执行CRUD操作。

因此，为了确保数据库类有一个对象，并且该对象将在整个应用程序中使用，我们实现了单例设计模式。

确保构造函数是私有的，并且提供了一个静态方法来提供对单例类的单个对象的访问

首先，让我们区分一下单对象和单对象。后者是前者的许多可能实现之一。而且单对象的问题与单例的问题是不同的。单对象本身并不坏，有时是做事情的唯一方法。简而言之:

单对象-我只需要程序中对象的一个实例 Singleton -创建一个带有静态字段的类。添加一个返回此字段的静态方法。在第一次调用时惰性地实例化一个字段。总是返回相同的对象。

public class Singleton {
    private static Singleton instance;

    private Singleton() {}

    public static Singleton instance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

如您所见，规范形式的“单例”模式对测试不是很友好。不过，这个问题很容易解决:只要让Singleton实现一个接口。让我们称它为“可测试单例”:)

public class Singleton implements ISingleton {
    private static Singleton instance;

    private Singleton() {}

    public static ISingleton instance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

现在我们可以模拟Singleton了，因为我们通过接口来使用它。其中一项索赔消失了。让我们看看是否可以去掉另一个声明-共享全局状态。

如果我们剥离单例模式，它的核心是惰性初始化:

public static ISingleton instance() {
    if (instance == null) {
        instance = new Singleton();
    }
    return instance;
}

这就是它存在的全部原因。这就是单对象模式。我们把它拿走，放到工厂方法中，例如:

public class SingletonFactory {
    private static ISingleton instance;

    // Knock-knock. Single Object here
    public static ISingleton simpleSingleton() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

与我们的可测试单例有什么不同?没有，因为这是单对象模式的本质——不管你是把它实现为单例、工厂方法还是服务定位器。你仍然有一些共享的全局状态。如果从多个线程访问它，这可能会成为一个问题。您将不得不使simpleSingleton()同步并处理所有多线程问题。

再说一遍:无论你选择什么方法，你都必须付出单一对象的代价。使用依赖注入容器只是将复杂性转移到框架，它将不得不处理单对象的固有问题。

回顾:

Most of people who mention Singleton mean Single Object One of the popular ways to implement it is the Singleton pattern It has its flaws that can be mitigated However, the most of Singleton's complexity roots in Single Object's complexity Regardless of how you instantiate your Single Object, it's still there, be it a Service Locator, a Factory Method or something else You can shift the complexity to a DI container which is (hopefully) well-tested Sometimes using the DI container is cumbersome - imagine injecting a LOGGER to every class