免責事項：私はすべての素晴らしい答えを要約し、私の言葉でそれを書きました。
シングルトンを実装する場合、2つのオプションがあります
。1。遅延読み込み
2.早期読み込み
遅延読み込みはビットオーバーヘッドを追加するので（非常に多くの場合正直です）、非常に大きなオブジェクトまたは重い構築コードがあり、インスタンスが必要になる前に使用できる他のアクセス可能な静的メソッドまたはフィールドがある場合にのみ使用します。遅延初期化を使用する必要があります。それ以外の場合は、早期ロードを選択することをお勧めします。
シングルトンを実装する最も簡単な方法は
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return INSTANCE;
}
}
初期にロードされたシングルトンを除き、すべてが良好です。遅延ロードされたシングルトンを試してみましょう
class Foo {
// Our now_null_but_going_to_be sole hero
private static Foo INSTANCE = null;
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
// Creating only when required.
if (INSTANCE == null) {
INSTANCE = new Foo();
}
return INSTANCE;
}
}
これまでのところ良いですが、ヒーローは、ヒーローの多くのインスタンスを必要とする複数の邪悪な糸で一人で戦っている間は生き残ることができません。だから悪マルチスレッドからそれを保護しましょう
class Foo {
private static Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
// No more tension of threads
synchronized (Foo.class) {
if (INSTANCE == null) {
INSTANCE = new Foo();
}
}
return INSTANCE;
}
}
でもヒーローを守るには十分ではありません、本当に!!! これは私たちのヒーローを助けるために私たちができる/すべきベストです
class Foo {
// Pay attention to volatile
private static volatile Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
if (INSTANCE == null) { // Check 1
synchronized (Foo.class) {
if (INSTANCE == null) { // Check 2
INSTANCE = new Foo();
}
}
}
return INSTANCE;
}
}
これは、「ダブルチェックロックイディオム」と呼ばれます。揮発性のステートメントを忘れがちであり、なぜそれが必要なのかを理解するのは困難です。
詳細：http : //www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
今、私たちは邪悪なスレッドについて確信していますが、残酷な連載についてはどうですか？デシリアライゼーション中に新しいオブジェクトが作成されないことを確認する必要があります
class Foo implements Serializable {
private static final long serialVersionUID = 1L;
private static volatile Foo INSTANCE = null;
// Rest of the things are same as above
// No more fear of serialization
@SuppressWarnings("unused")
private Object readResolve() {
return INSTANCE;
}
}
メソッドreadResolve()は、オブジェクトがプログラムの以前の実行でシリアル化された場合でも、唯一のインスタンスが返されることを確認します。
最後に、スレッドとシリアル化に対する十分な保護を追加しましたが、コードはかさばって醜く見えます。私たちのヒーローに変身させましょう
public final class Foo implements Serializable {
private static final long serialVersionUID = 1L;
// Wrapped in a inner static class so that loaded only when required
private static class FooLoader {
// And no more fear of threads
private static final Foo INSTANCE = new Foo();
}
// TODO add private shouting construcor
public static Foo getInstance() {
return FooLoader.INSTANCE;
}
// Damn you serialization
@SuppressWarnings("unused")
private Foo readResolve() {
return FooLoader.INSTANCE;
}
}
はい、これはまったく同じヒーローです:)
行private static final Foo INSTANCE = new Foo();はクラスFooLoaderが実際に使用されたときにのみ実行されるので、これは遅延インスタンス化を処理します、
スレッドセーフであることが保証されています。
これまでのところ、私たちが行ったすべてを達成するための最善の方法が最善の方法です
public enum Foo {
INSTANCE;
}
内部的には次のように扱われます
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
}
それでおしまい！シリアル化、スレッド、醜いコードを恐れる必要はもうありません。また、ENUMSシングルトンは遅延初期化されます。
このアプローチは、機能がパブリックフィールドアプローチと同等ですが、より簡潔であり、シリアル化機構を無料で提供し、洗練されたシリアル化またはリフレクション攻撃に直面しても、複数のインスタンス化に対する強力な保証を提供します。このアプローチはまだ広く採用されていませんが、単一要素の列挙型がシングルトンを実装する最良の方法です。
-「Effective Java」のJoshua Bloch
これで、ENUMSがシングルトンを実装する最良の方法と見なされている理由に気付いたかもしれません。忍耐力に感謝します:)
私のブログで更新しました。