シングルトンを壊さないでください! Java で % スレッドセーフにする方法は次のとおりです-＆＃＆チュートリアル-php.cn

Don’t Let Your Singleton Break! Here’s How to Make It % Thread-Safe in Java

この投稿では、積極的な初期化、二重チェックロック、および 内部静的クラス アプローチ。シングルトンの整合性を確保する上で、final キーワードがなぜ有益なのかについても説明します。

シングルトンを使用する理由

シングルトンは、アプリケーション全体でクラスの

1 つのインスタンスが必要な場合に便利です。一般的な使用例には、ロギング、構成、接続プールなどの共有リソースの管理が含まれます。シングルトンは、クラスにアクセスする複数のリクエストが、新しいインスタンスを作成するのではなく、確実に同じインスタンスを共有するようにします。

1. 積極的な初期化: 最も単純なシングルトン

積極的な初期化パターンは、クラスがロードされるときにシングルトンインスタンスを作成します。これは簡単で、クラスが JVM によってロードされるときにインスタンスが作成されるため、スレッドの安全性が確保されます。

public final class Singleton {
    // Instance is created at class loading time
    private static final Singleton INSTANCE = new Singleton();

    // Private constructor prevents instantiation from other classes
    private Singleton() {}

    public static Singleton getInstance() {
        return INSTANCE;
    }
}

ログイン後にコピー

Eager Initialization の長所と短所

長所:

短所:

いつ使用するか: シングルトンクラスが軽量で、アプリケーションの実行時に使用されることが確実な場合は、即時初期化が最適です。

2. 二重チェックされたロックによる遅延初期化

必要になるまでシングルトンの作成を遅らせたい場合 (

遅延初期化と呼ばれる) には、二重チェックされたロックがスレッドセーフなソリューションを提供します。最小限の同期を使用し、初めてアクセスしたときにのみインスタンスが作成されるようにします。

public final class Singleton {  // Marked as final to prevent subclassing

    // volatile ensures visibility and prevents instruction reordering
    private static volatile Singleton instance;

    // Private constructor prevents instantiation from other classes
    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {               // First check (no locking)
            synchronized (Singleton.class) {   // Locking
                if (instance == null) {        // Second check (with locking)
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

ログイン後にコピー

二重チェックロックが機能する理由

最初のチェック: 同期ブロックの外側の if (instance == null) チェックにより、getInstance() が呼び出されるたびにロックすることを回避できます。これにより、初期化後の将来の呼び出しに対して同期ブロックがバイパスされるため、パフォーマンスが向上します。
同期ブロック: インスタンスが null になると、同期ブロックに入ると、1 つのスレッドのみがシングルトンインスタンスを作成するようになります。このポイントに到達する他のスレッドは待機する必要があり、競合状態が防止されます。
2 番目のチェック: 同期ブロック内で、インスタンスを再度チェックして、現在のスレッドが待機している間に他のスレッドがインスタンスを初期化していないことを確認します。この二重チェックにより、シングルトンインスタンスが 1 つだけ作成されることが保証されます。

なぜ揮発性が必要なのか

volatile キーワードは、命令の並べ替えを防ぐために、二重チェックされたロックパターンに不可欠です。これがないと、ステートメント instance = new Singleton(); になります。完全に初期化される前に他のスレッドに対して完了したように見える可能性があり、部分的に構築されたインスタンスが返されることになります。 volatile は、インスタンスが null でなくなると、完全に構築され、すべてのスレッドに表示されることを保証します。

ファイナルがグッドプラクティスである理由

ここでは、サブクラス化を防ぐために、final キーワードが使用されています。 Singleton クラスを Final としてマークすると、次の 2 つの主な利点があります。

サブクラス化の防止: クラスを Final にすることで、他のクラスがそのクラスを拡張できなくなります。これにより、サブクラス化により追加のインスタンスが生成され、シングルトンパターンが崩れる可能性があるため、シングルトンクラスのインスタンスは 1 つだけ存在できることが保証されます。
Signals Immutability: Final は、シングルトンクラスが不変であることを意図しており、拡張すべきではないことを他の開発者に明確に示すものとして機能します。これにより、コードの理解と保守が容易になります。

つまり、final はシングルトンの整合性を強化し、サブクラス化による予期せぬ動作を回避するのに役立ちます。

二重チェックロックの長所と短所

長所:

遅延初期化は、必要になるまで作成を遅らせてリソースを節約します。
二重チェックによる同期オーバーヘッドが最小限に抑えられます。

短所:

少し複雑で、安全のために揮発性が必要です。
積極的な初期化で十分な、より単純なシングルトンのニーズには過剰になる可能性があります。

使用する場合: このパターンは、シングルトンクラスがリソースを大量に消費し、常に必要になるとは限らない場合、またはマルチスレッド環境でのパフォーマンスが懸念される場合に役立ちます。

3. 内部静的クラス: よりクリーンな遅延初期化の代替手段

遅延初期化に対する代替のスレッドセーフなアプローチは、内部静的クラス パターンです。これは、Java のクラスローディングメカニズムを利用して、明示的な同期を行わずに、必要な場合にのみシングルトンインスタンスを初期化します。

public final class Singleton {
    // Instance is created at class loading time
    private static final Singleton INSTANCE = new Singleton();

    // Private constructor prevents instantiation from other classes
    private Singleton() {}

    public static Singleton getInstance() {
        return INSTANCE;
    }
}

ログイン後にコピー