Java のシングルトン モードにおけるスレッド セーフティの問題の解決策

この記事では、主に Java シングルトン モードのスレッド セーフの問題に関する関連情報を紹介します。この記事を通じて、誰もがシングルトン モードでのスレッド セーフの使用を理解し、習得できることを願っています。

Java シングルトン モードのスレッド セーフ。問題

SpringIOC コンテナは、デフォルトでシングルトン モードで Bean アクセス スコープを提供します。つまり、アプリケーションのライフサイクル全体でインスタンスは 1 つだけです。したがって、マルチスレッドの同時実行では、スレッドの安全性のリスクが発生します。 MVC フレームワークに基づくサーブレットはスレッドセーフです。サーブレットはクライアント側にあるため、同時実行性は比較的低いですが、Web サービス側ではそれを考慮する必要があります。

ThreadLocal クラス: 各スレッドに変数 (インスタンス) の独立したコピーを提供し、それぞれの異なるインスタンスから分離にアクセスします。
同期ロックメカニズムでは、後発スレッドは、メンバー変数にアクセスする前に、先行スレッドが完了するのを待ちます。 ThreadLocal はインスタンスのレプリケーションを実装し、オブジェクト アクセス データの競合を分離します。同時に、プロトタイプアクセスモードでの多数のインスタンスのライフサイクル管理の少量の消費と負担も解決できます。それは、「時間と空間の交換」と「空間と時間の交換」の二つの実現です。前者は、異なるスレッドがアクセスのためにキューに入れるための一意の変数のみを提供しますが、後者は各スレッドにコピーを提供するため、相互に影響を与えることなく同時にアクセスできます。同時に、コピーは に保存されます。メモリが消費され、次回からはインスタンスが再生成されなくなり、サーバー リソースの消費が削減されます。

Spring では、一般にステートレス Bean のみがマルチスレッド環境で共有できることがわかっています。ほとんどの Bean はシングルトン スコープとして宣言できます。これは、ステートフル Bean は複数のスレッド間で共有できるため、Spring は ThreadLocal を使用して一部の Bean (RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder など) の非スレッドセーフ状態を処理し、スレッドセーフにするためです。

スレッド セーフティの問題: グローバル変数と静的変数が原因で発生します。各スレッドにグローバル変数と静的変数の読み取り操作のみがあり、書き込み操作が存在しない場合、一般的に、複数のグローバル変数が存在する場合、このグローバル変数はスレッド セーフです。スレッドが同時に書き込み操作を実行する場合、通常、スレッドの同期を考慮する必要があります。そうしないと、スレッドの安全性が影響を受ける可能性があります。

1) 定数は常にスレッドセーフです (定数値)
2) 各メソッド呼び出しの前に新しいインスタンスを作成することはスレッドセーフです。 (異なるインスタンスは互いに分離されます)
3) ローカル変数はスレッドセーフ(分離)されます

メソッドが実行されるたびに、ローカル変数は独立した空間に作成されるため、共有リソースではありません。ローカル変数には、メソッド パラメーター変数とメソッド内部変数が含まれます。

ステータス: データ保存と変更機能付き。インスタンス変数を持つオブジェクトであるステートフル Bean はデータを保存できますが、スレッドセーフではありません。

ステートレス: これは 1 回限りの操作であり、データは変更できません。 Stateless Bean はインスタンス変数を持たないオブジェクトであり、データを保存できず、不変クラスであり、スレッドセーフです。春には、パフォーマンスを向上させるためにシングルトン モードが共有インスタンスになります。ステートフル Bean はマルチスレッド環境では安全ではないため、Prototype プロトタイプ モードが適しています。プロトタイプ: Bean に対するリクエストごとに、新しい Bean インスタンスが作成されます。

以上がJava のシングルトン モードにおけるスレッド セーフティの問題の解決策の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。