8

必ずしもシングルトン パターンを使用して実装するという意味ではなく、プールの 1 つのインスタンスのみを使用して実装することを意味します。プールを 1 つだけ (またはプールされたタイプごとに 1 つ) 持つという考えは好きではありません。ただし、可変型の複数のプールに利点がある具体的な状況を実際に思いつくことはできません。少なくとも、単一のプールが同様に機能する場合はそうではありません。

シングルトン プールよりも複数のプールを使用することには、どのような利点がありますか?

4

3 に答える 3

3

はい、確かに複数のオブジェクト プールを持つ潜在的な理由があります。特に、1 つのプールをガベージ コレクションの対象にする (または手動で解放するなど) 一方で、他のプールを保持したい場合があります。

たとえば、文字列のオブジェクト プールを考えてみましょう。これは、XML のコンテキストでは非常に便利です。同じスキーマの複数の XML ドキュメントを解析している場合、要素名と属性名に使用される文字列をプールしたい場合があります。ただし、これらの名前の処理の一部が終了すると、二度と使用されない可能性があります。そのため、別のドキュメント セットに移動するときは、別のプールを使用することをお勧めします。両方のタスクを同時に実行することになる場合があります。その場合、両方のプールを同時に使用できるようにしておくと便利です。

または、スレッド プールを検討してください。基本的にシステム スレッド プールが 1 つしかないことは、.NET スレッド プールの実装の欠点だと思います。サーバーで複数のスレッド プールを使用できるというアイデアが気に入っています。いくつかの優先度の低いバッチ ジョブ用のスレッド、いくつかの「通常の」リクエスト用のスレッド、およびヘルス モニタリングなどのジョブ用のいくつかの優先度の高いスレッドです。

于 2011-02-09T19:28:29.987 に答える
2

シングルトンプールよりも複数のプールを持つことにはどのような利点がありますか？

ThreadPoolのように、私たちが使用するほとんどのオブジェクトプールは、単純化のためにシングルトンとして実装されていると思います。その点で、これらのプールの設計者は、複数インスタンスのプールでも目的を見ていませんでした。

ただし、実際に複数のプールがある場所はいくつかあります。IISアプリケーションプールとデータベース接続プールです。

アプリプール

IISでは、複数のアプリケーションプールを構成して、関連するWebアプリケーションがすべて独自のプールで実行されるようにすることができます。この設計にはいくつかの利点があり、その利点はIISの外部のプール実装に一般化できます。

  • 複数のオブジェクトプールを使用するとある程度の分離が可能になるため、1つのプールでエラーが発生しても、他のプールのオブジェクトに影響を与えることはありません。

  • 各プールは異なるユーザーの下で実行できるため、アプリケーションプールに基づいて異なるレベルのセキュリティが提供されます。

  • 各プールは、エラーに対して異なるハンドラーを持つことができます。

  • 各プールは、異なるバージョンの.NETFrameworkで実行できます。

  • 各プールには、独自のHTTPタイムアウトを設定できます。

接続プール

SQL Serverでは、データベースへの複数の呼び出しで接続プールを使用して、クエリごとに新しいデータベース接続を作成するオーバーヘッドを回避しますが、SQLServerは接続文字列ごとに新しいプールを作成します。この設計の背後にある理論的根拠は次のとおりだと思います。

  • 各プールは、特定のデータベースインスタンスへの接続を保持します。すべての接続を含むプールが1つしかない場合は、要求した接続文字列に一致する接続が見つかるまで、すべての接続を検索する必要があります。接続文字列ごとに複数のプールがあるため、他の接続を検索せずに、その特定のプールから最初に使用可能な接続を簡単に取得できます。

  • 言い換えると、SQL Serverは、データベース接続をすばやく取得するための最適化として複数の接続プールを使用しているのではないかと思います。

  • また、これらの接続はすべて、接続プールに固有のリソースを共有している可能性があります。これは、単一のプールでは不可能な場合があります。たとえば、接続文字列ごとの最大接続プールサイズを指定できます。シングルプール設計を使用して、特定のデータベースへの同時接続の数を制御できない場合があります。

プールを設計する方法

デザインから本当に必要なものを見ずに、複数のプールを使用するか、単一のプールを使用するかを実際に選択することはできません。

非常に単純なオブジェクトプールがある場合は、シングルトンデザインでうまくいく可能性があります。柔軟性やカスタマイズが本当に必要な場合、または複数のプロセスやマシンに分散されたオブジェクトプールのような非常にユニークなセットアップがある場合は、代わりにn-gleton設計のメリットを確実に享受できます。

于 2011-02-09T22:55:34.573 に答える
0

シングルトンパターンを注意深く実装すれば、後で気が変わる可能性があります。ファクトリメソッドの背後にあるクラスのシングルトン性をカプセル化するだけです。すべてがそれを使用している場合は、正当な理由があるときに、後で複数のインスタンスを持つことを許可できます。

public class MyClass
{
    public static MyClass GetInstance()
    {
          return singleton_ ?? (singleton = new MyClass());
    }
}
于 2011-02-13T15:21:20.053 に答える