单例的延迟初始化

Question

在阅读Jon Skeet's article on singletons in C# 时，我开始想知道为什么我们首先需要延迟初始化。看来文章中的第四种方法应该足够了，这里仅供参考：

public sealed class Singleton
{
    static readonly Singleton instance=new Singleton();

    // Explicit static constructor to tell C# compiler
    // not to mark type as beforefieldinit
    static Singleton()
    {
    }

    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            return instance;
        }
    }
}

在极少数情况下，如果您在单例上有其他静态方法，延迟初始化可能会有好处，但这不是一个好的设计。

那么人们能告诉我为什么延迟初始化如此热门吗？

Answer 1

在那些你正在初始化的东西可能根本不需要并且初始化成本很高的场景中（就 CPU 周期或资源而言），然后在对象的情况下实现惰性初始化器可以节省成本不需要。

如果对象总是需要，或者初始化相对便宜，那么惰性初始化器不会带来额外的好处。

无论如何，不​​正确地实现惰性初始化器可能会使单例非线程安全，因此如果您需要这种模式，请小心正确地执行。 Jon 的文章有一个模式，（我认为这是最后一个）解决了这个问题。

Answer 2

如果您要使用该类型的唯一原因是引用实例，则您不需要对单例进行延迟初始化。

但是，如果您引用类型或类型本身的任何其他属性或方法，您将初始化单例。

诚然，好的设计会将一项任务留给一种类型，所以这应该不是问题。但是，如果您将单例类设置为“复杂”，则延迟初始化可以帮助您避免因过早初始化而产生后果。

Answer 3

我不确定这是否也适用于 C#，但我会回答 C++：

单例背后的一个想法是静态对象的初始化顺序是不确定的。因此，如果您有一个静态类尝试使用另一个静态类，您可能会遇到麻烦。

一个具体的例子：假设我有一个 Log 类，我决定将其实现为 Singleton。我们还假设我有一个名为 LoadDB 的方法，无论出于何种原因，它都是在程序开始时调用的静态方法。假设 LoadDB 决定它需要记录一些东西，它将调用 Singleton。但是由于静态初始化的顺序是不确定的，它可能正在做一些错误的事情。

Singleton 解决了这个问题，因为一旦您调用 GetInstance()，无论您在初始化过程中的哪个位置，都保证该对象存在。

同样，我不知道这是否相关，但至少这是它的历史（据我所知）。

Answer 4

从 Java DI 的角度来看，延迟初始化很好，在另一个 API 中总是有（比如 spring）bean，你可能不想使用，例如，一个急切加载的单例缓存（与使用cache) 可能不需要您，尽管它可能在您的同一代码中被称为依赖项。加载单例浪费资源有什么意义？

惰性初始化实现选择很棘手，在spring中，你会选择lazy-init="true"（spring急切地实例化单例）、init-method/destroy-method、@PostConstruct、InitializingBean - afterPropertiesSet() 方法还是在 getInstance() 方法中返回相同的弹簧实例？

选择是在可测试性与弹簧容器外的可重用性之间进行权衡。