Java實現單例的難點

有簡單又高效的方法能夠實現單例模式，但沒有一種方式能在任何狀況下都確保單例的完整性。

單例模式是指某個類只被實例化一次，用來表示全局或系統範圍的組件。單例模式經常使用於日誌記錄、工廠、窗口管理器和平臺組件管理等。我認爲要儘可能避免使用單例模式，由於一旦實現就很難改變或重載，並且會形成編寫測試用例困難、代碼結構糟糕等問題。另外，下面文章中的單例模式是不安全的。

人們花大量的精力研究怎樣更好地實現單例模式，但有一種簡單高效的實現方法。然而，沒有一種方法能在任何狀況下都確保單例的完整性。閱讀下文，看看你是否定同。

Final字段

這種方法將構造函數私有化，向外提供一個公有的static final對象：

public class FooSingleton {
    public final static FooSingleton INSTANCE = new FooSingleton();
    private FooSingleton() { }
    public void bar() { }
}

類加載時，static對象被初始化，此時私有的構造函數被第一次也是最後一次調用。即便在類初始化前有多個線程調用此類，JVM也能保證線程繼續運行時該類已完整初始化。然而，使用反射和setAccessible(true)方法，能夠建立其餘新的實例：

Constructor[] constructors = FooSingleton.class.getDeclaredConstructors();
Constructor constructor = constructors[0];
constructor.setAccessible(true);
FooSingleton spuriousFoo = (FooSingleton) constructor.newInstance(new Object[0]);

咱們須要修改構造函數，使其免於屢次調用，例如當它被再次調用時拋出異常。以下這樣修改FooSingleton構造函數，能夠防範此類攻擊：

public class FooSingleton2 {
    private static boolean INSTANCE_CREATED;
    public final static FooSingleton2 INSTANCE = new FooSingleton2();
    private FooSingleton2() {
        if (INSTANCE_CREATED) {
            throw new IllegalStateException("You must only create one instance of this class");
        } else {
            INSTANCE_CREATED = true;
        }
    }
    public void bar() { }
}

這樣看起來安全一些了，但其實要建立新的實例仍是同樣容易。咱們只需修改INSTANCE_CREATED字段，再玩一樣的把戲就能夠了：

Field f = FooSingleton2.class.getDeclaredField("INSTANCE_CREATED");
f.setAccessible(true);
f.set(null, false);
Constructor[] constructors = FooSingleton2.class.getDeclaredConstructors();
Constructor constructor = constructors[0];
constructor.setAccessible(true);
FooSingleton2 spuriousFoo = (FooSingleton2) constructor.newInstance(new Object[0]);

咱們採起的任何防範措施均可能被繞過，因此此方案並不可行。

 

靜態工廠

使用這種方法，公有的成員相似靜態工廠：

public class FooSingleton3 {
    public final static FooSingleton3 INSTANCE = new FooSingleton3();
    private FooSingleton3() { }
    public static FooSingleton3 getInstance() { return INSTANCE; }
    public void bar() { }
}

getInstance()方法返回的永遠是同一個對象引用。雖然這個方案也沒法防範反射，但仍是有它的一些優勢。例如，能夠在不改變API的狀況下，改變單例的實現。getInstance()出如今幾乎全部的單例實現中，它也標誌着這真的是一個單例模式。

延遲加載的單例模式

（譯者注：在軟件工程中，Initialization-on-demand holder 這個習語指的就是延遲加載的單例模式，參見維基百科）

若是但願儘量延遲單例的建立（懶漢式加載），可使用延遲初始化方法，當getInstance()方法第一次調用時線程安全地建立單例。相比以前的方案當第一次引用該類時就建立單例（餓漢式加載），這是一個進步。以下：

public class FooSingleton4 {
    private FooSingleton4() {
    }
    public static FooSingleton4 getInstance() {
        return FooSingleton4Holder.INSTANCE;
    }
    private static class FooSingleton4Holder {
        private static final FooSingleton4 INSTANCE = new FooSingleton4();
    }
}

要當心序列化

若是單例實現了序列化，它就要面臨另外一個威脅。所以須要將全部字段聲明爲transient（這樣它就不會被序列化）並提供一個自定義的readResolve()方法返回惟一實例INSTANCE的引用。

 

枚舉

這裏用枚舉做爲單例INSTANCE的容器：

public enum FooEnumSingleton {
    INSTANCE;
    public static FooEnumSingleton getInstance() { return INSTANCE; }
    public void bar() { }
}

根據Java語言規範8.9，「Enum的final克隆方法保證枚舉永遠沒法被克隆，其特殊的序列化機制保證沒法反序列化獲得拷貝的對象。同時，還禁止利用反射對枚舉進行實例化。保證了這四個方面，在枚舉常量以外，就不會有其餘同類的枚舉實例存在。」

這樣，咱們彷佛很簡單地就防範了序列化、克隆和反射的攻擊。第一次看到這段話，我馬上想要證實它是錯的。以下代碼所示，繞過這些保護是很容易的：

Constructor con = FooEnumSingleton.class.getDeclaredConstructors()[0];
 Method[] methods = con.getClass().getDeclaredMethods();
 for (Method method : methods) {
     if (method.getName().equals("acquireConstructorAccessor")) {
         method.setAccessible(true);
         method.invoke(con, new Object[0]);
     }
  }
  Field[] fields = con.getClass().getDeclaredFields();
  Object ca = null;
  for (Field field : fields) {
      if (field.getName().equals("constructorAccessor")) {
          field.setAccessible(true);
          ca = field.get(con);
      }
  }
  Method method = ca.getClass().getMethod("newInstance", new Class[]{Object[].class});
  method.setAccessible(true);
  FooEnumSingleton spuriousEnum = (FooEnumSingleton) method.invoke(ca, new Object[]{new Object[]{"SPURIOUS_INSTANCE", 1}});
  printInfo(FooEnumSingleton.INSTANCE);
  printInfo(spuriousEnum);
}
private static void printInfo(FooEnumSingleton e) {
    System.out.println(e.getClass() + ":" + e.name() + ":" + e.ordinal());
}

執行這段代碼，獲得結果：

class com.blogspot.minborgsjavapot.singleton.FooEnumSingleton:INSTANCE:0
class com.blogspot.minborgsjavapot.singleton.FooEnumSingleton:SPURIOUS_INSTANCE:1

枚舉的缺點是它沒法從另外一個基類繼承，由於它已經繼承自java.lang.Enum。若是想要模擬這種繼承，能夠參考我另外一篇文章中介紹的混入模式（mixin pattern）。

枚舉的一個優勢是，若是你以後但願有「二例（dualton）」或「三例（tringleton）」，只須要增長新的枚舉實例便可。例如，有了一個單例的緩存以後，你也許還想給緩存引入多個層次。

 

結論

儘管繞過單例的這些保護並不容易，但確實沒有一種萬無一失的方案。若是你有更好的方案，請不吝賜教！

枚舉是實現單例模式的簡單而又高效的方法。若是想要有繼承或懶漢式加載，延遲初始化方案是不錯的選擇。

祝你的單例好運！

 

原文連接： dzone 翻譯： rainsbaby
譯文連接： http://www.importnew.com/16995.html