初始化可能失败的惰性单例的哪种实现？

Question

想象一下，您有一个静态无参方法，它是幂等的并且始终返回相同的值，并且可能会抛出检查异常，如下所示：

class Foo {
 public static Pi bar() throws Baz { getPi(); } // gets Pi, may throw 
}

现在，如果构造返回对象的内容很昂贵，那么这是惰性单例的良好候选者并且永远不会改变。一种选择是 Holder 模式：

class Foo {
  static class PiHolder {
   static final Pi PI_SINGLETON = getPi();
  }
  public static Pi bar() { return PiHolder.PI_SINGLETON; }
}

不幸的是，这行不通，因为我们不能从（隐式）静态初始化块中抛出已检查的异常，因此我们可以尝试这样的方法（假设我们想要保留调用者在调用 bar() 时获得已检查的异常）：

class Foo {
  static class PiHolder {
   static final Pi PI_SINGLETON;
   static { 
    try { 
     PI_SINGLETON =  = getPi(); }
    } catch (Baz b) {
     throw new ExceptionInInitializerError(b);
    }
  }

  public static Pi bar() throws Bar {
   try {
    return PiHolder.PI_SINGLETON;
   } catch (ExceptionInInitializerError e) {
    if (e.getCause() instanceof Bar)
     throw (Bar)e.getCause();
    throw e;
   }
}

此时，也许双重检查锁定更干净？

class Foo {
 static volatile Pi PI_INSTANCE;
 public static Pi bar() throws Bar {
  Pi p = PI_INSTANCE;
  if (p == null) {
   synchronized (this) {
    if ((p = PI_INSTANCE) == null)
     return PI_INSTANCE = getPi();
   }
  }
  return p;
 }
}

DCL 仍然是一种反模式吗？我这里还缺少其他解决方案吗（也可以使用诸如活泼的单一检查之类的小变体，但不会从根本上改变解决方案）？有充分的理由选择其中之一吗？

我没有尝试上面的例子，所以它们完全有可能无法编译。

编辑：我没有能力重新实现或重新架构这个单例的消费者（即Foo.bar()的调用者），也没有我有机会介绍一个DI框架来解决这个问题吗？我最感兴趣的是在给定的约束内解决问题的答案（提供一个带有传播给调用者的已检查异常的单例）。

更新：我最终决定选择 DCL，因为它提供了保留现有合同的最干净的方式，并且没有人提供为什么应该避免正确执行 DCL 的具体原因。我没有在接受的答案中使用该方法，因为它似乎是实现相同目标的一种过于复杂的方法。

Answer 1

“Holder”技巧本质上是由 JVM 执行的双重检查锁定。根据规范，类初始化处于（双重检查）锁定状态。 JVM 可以安全（快速）地执行 DCL，不幸的是，Java 程序员无法获得这种能力。我们能做的最接近的是通过中间最终参考。请参阅有关 DCL 的维基百科。

您保留异常的要求并不难：

class Foo {
  static class PiHolder {
    static final Pi PI_SINGLETON;
    static Bar exception;
    static { 
      try { 
        PI_SINGLETON =  = getPi(); }
      } catch (Bar b) {
        exception = b;
      }
    }
  }
public Pi bar() throws Bar {
  if(PiHolder.exception!=null)
    throw PiHolder.exception;  
  else
    return PiHolder.PI_SINGLETON;
}

Answer 2

我强烈建议扔掉单例和可变静态。 “正确使用构造函数。”构造对象并将其传递给需要它的对象。

Answer 3

根据我的经验，当您尝试获取的对象需要的不仅仅是简单的构造函数调用时，最好使用依赖项注入。

public class Foo {
  private Pi pi;
  public Foo(Pi pi) {
    this.pi = pi;
  }
  public Pi bar() { return pi; }
}

...或者如果惰性很重要：（

public class Foo {
  private IocWrapper iocWrapper;
  public Foo(IocWrapper iocWrapper) {
    this.iocWrapper = iocWrapper;
  }
  public Pi bar() { return iocWrapper.get(Pi.class); }
}

具体细节在某种程度上取决于您的 DI 框架）

您可以告诉 DI 框架将对象绑定为单例。从长远来看，这为您提供了更大的灵活性，并使您的类更易于进行单元测试。

此外，我的理解是，由于 JIT 编译器可能对指令进行重新排序，Java 中的双重检查锁定不是线程安全的。 编辑：正如 Meron 指出的那样，双重检查锁定可以在 Java 中工作，但您必须使用 volatile 关键字。

最后一点：如果您使用良好的模式，通常很少或没有理由希望您的类被延迟实例化。最好让您的构造函数非常轻量，并将大部分逻辑作为方法的一部分执行。我并不是说在这种特殊情况下你一定做错了什么，但你可能想更广泛地了解如何使用这个单例，看看是否没有更好的方法来构建事物。

Answer 4

由于您没有告诉我们您需要什么，因此很难提出更好的实现方法。我可以告诉你，懒惰的单例很少是最好的方法。

不过，我可以看到您的代码有几个问题：

try {
    return PiHolder.PI_SINGLETON;
} catch (ExceptionInInitializerError e) {

您如何期望字段访问抛出异常？

---

编辑：正如 Irreputable 所指出的，如果访问导致类初始化，并且初始化因静态初始化器抛出异常而失败，那么您实际上会在这里得到 ExceptionInInitializerError 。但是，VM 在第一次失败后不会尝试再次初始化该类，并使用不同的异常进行通信，如以下代码所示：

static class H {
    final static String s; 
    static {
        Object o = null;
        s = o.toString();
    }
}

public static void main(String[] args) throws Exception {
    try {
        System.out.println(H.s);
    } catch (ExceptionInInitializerError e) {
    }
    System.out.println(H.s);
}

结果：

线程“main”java.lang.NoClassDefFoundError中出现异常：无法初始化类tools.Test$H 
        在tools.Test.main(Test.java:21)

而不是 ExceptionInInitializerError。

---

您的双重检查锁定也遇到类似的问题；如果构造失败，则该字段保持为空，并且每次访问 PI 时都会重新尝试构造 PI。如果失败是永久性的并且代价高昂，您可能希望采取不同的做法。