管理到数据库的连接(或连接池)。

我还会使用它来检索和存储外部配置文件中的信息。

在我寻求真相的过程中，我发现实际上很少有“可接受的”理由使用Singleton。

在互联网上反复出现的一个原因是“日志记录”类(你提到过)。在这种情况下，可以使用Singleton来代替类的单个实例，因为日志类通常需要被项目中的每个类反复使用，令人作呕。如果每个类都使用这个日志类，依赖注入就变得很麻烦。

日志记录是“可接受的”单例的一个特定示例，因为它不会影响代码的执行。禁用日志记录，代码执行保持不变。启用它，一样。Misko在《单例的根本原因》中这样说:“这里的信息单向流动:从应用程序流向记录器。即使记录器是全局状态，由于没有信息从记录器流入应用程序，记录器也是可以接受的。”

我相信还有其他合理的原因。Alex Miller在“我讨厌的模式”中谈到，服务定位器和客户端UI也可能是“可接受的”选择。

阅读更多在Singleton我爱你，但你让我失望。

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

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

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

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

单对象-我只需要程序中对象的一个实例 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

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

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

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

Ed.

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

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