我需要在并发环境中延迟加载资源。加载资源的代码应该只执行一次。
Double-checked locking（使用 JRE 5+ 和 volatile 关键字）和Initialization on demand holder idiom 似乎都非常适合这项工作。
仅通过查看代码，Initialization on demand holder 惯用语似乎更简洁、更高效（但是，嘿，我猜这里）。尽管如此，我还是必须注意并记录每个单身人士的模式。至少对我来说，很难理解为什么代码会在现场写成这样……
我的问题是：哪种方法更好？为什么？ 如果你的答案是否定的。您将如何在 Java SE 环境中解决此要求？
替代品
我可以为此使用 CDI 而不强制它在我的整个项目中使用吗？有文章吗？
【问题讨论】：
标签： java concurrency singleton lazy-loading design-patterns
添加另一个可能更简洁的选项。我建议使用枚举变体：
What is the best approach for using an Enum as a singleton in Java?
【讨论】：
Elvis.getAge() 需要一些非常密集的操作，我希望它们尽可能地延迟并且只执行一次。我应该把加载代码放在哪里？在枚举构造函数中？
Elvis 与INSTANCE1.getAge() 和INSTANCE2.getAge()。我可以让它们以线程安全的方式独立加载吗？
INSTANCE1.getAge() 延迟加载一个值而INSTANCE2.getAge() 延迟加载另一个值怎么办？在这两种情况下，他们都应该只加载它的值一次（并且单独加载）。是否有可能实现这种行为？ （多个枚举很好，我只是想知道它是否可以改进）。
就可读性而言，我会选择按需初始化。我觉得双重检查锁定是一个过时且丑陋的实现。
从技术上讲，通过选择双重检查锁定，您总是会在字段上产生易失性读取，而您可以使用按需初始化持有者习语进行正常读取。
【讨论】：
Initialisation-on-demand holder 仅适用于单例，您不能拥有每个实例延迟加载的元素。双重检查锁定给必须查看课程的每个人带来了认知负担，因为很容易以微妙的方式出错。在我们将模式封装到 our concurrency library 中的实用程序类之前，我们曾经遇到过各种各样的麻烦
我们有以下选择：
Supplier<ExpensiveThing> t1 = new LazyReference<ExpensiveThing>() {
protected ExpensiveThing create() {
… // expensive initialisation
}
};
Supplier<ExpensiveThing> t2 = Lazy.supplier(new Supplier<ExpensiveThing>() {
public ExpensiveThing get() {
… // expensive initialisation
}
});
就用法而言，两者具有相同的语义。第二种形式使内部供应商使用的任何引用在初始化后都可用于 GC。第二种形式还支持 TTL/TTI 策略的超时。
【讨论】：
Initialization-on-demand holder 始终是实现单例模式的最佳实践。它很好地利用了JVM的以下特性。
另外，您不必使用 synchronize 关键字，它会使您的程序慢 100 倍。
【讨论】：
我怀疑按需初始化持有人比双重检查锁定（使用易失性）稍微快一些。原因是前者在创建实例后没有同步开销，但后者涉及读取 volatile（我认为）需要完整的内存读取。
如果性能不是一个重要的问题，那么同步的getInstance() 方法是最简单的。
【讨论】：