ガベージコレクターはWebサービス参照をクリーンアップしますか、それとも呼び出したメソッドの呼び出しが終了した後にサービス参照でdisposeを呼び出す必要がありますか?
5 に答える
Web サービスの破棄について心配する代わりに、シングルトン パターンを使用して、各 Web サービスのインスタンスを 1 つだけ保持できます。Web サービスはステートレスであるため、Web サーバー上の接続とスレッド間で安全に共有できます。
Web サービス インスタンスへの参照を保持するために使用できる Web サービス クラスの例を次に示します。このシングルトンはレイジーでスレッドセーフです。シングルトンを遅延させる場合は、同じロジックに従ってスレッド セーフに保つことをお勧めします。これを行う方法の詳細については、シングルトンの実装に関する C# の詳細記事を参照してください。
また、WCF Web サービスで問題が発生する可能性があることにも注意してください。詳細については、 WCF のインスタンス管理手法の記事、特にシングルトンのセクションを読むことをお勧めします。
public static class WS
{
private static object sync = new object();
private static MyWebService _MyWebServiceInstance;
public static MyWebService MyWebServiceInstance
{
get
{
if (_MyWebServiceInstance == null)
{
lock (sync)
{
if (_MyWebServiceInstance == null)
{
_MyWebServiceInstance= new MyWebService();
}
}
}
return _MyWebServiceInstance;
}
}
}
そして、Web サービスにアクセスする必要がある場合は、次のようにします。
WS.MyWebServiceInstance.MyMethod(...)
また
var ws = WS.MyWebServiceInstance;
ws.MyMethod(...)
私はいくつかのプロジェクトでこのパターンをうまく使用しており、うまく機能していますが、以下のコメントで tvanfosson が言及しているように、DI フレームワークを使用して Web サービス インスタンスを管理することは、さらに優れた戦略です。
DataService は Component から Dispose を継承していると思います。
IDispose を実装するオブジェクトは、ガベージ コレクターを支援するために手動で破棄する必要があります。
反対する場合は、using
ブロックを使用してください。保持できるオブジェクトについては、それらを保持しているオブジェクトも破棄されるときにそれらを破棄するようにします。
ここで何を達成しようとしていますか?
パフォーマンスが心配な場合は、Web サービスをホストするサーバーの応答性とネットワーク速度についてもっと心配します。Web サービスの呼び出しが完了するまでの待機時間に劇的な影響を与える可能性があるためです (非同期でない限り)。
MSDN の例では「Dispose」を呼び出しておらず、ガベージ コレクターがその仕事を行うことは明らかです。そのため、メモリ内で毎秒 100,000 を超えるレコードを処理する必要があるリアルタイム システムで作業していない限り、おそらくあなたが立ち上がる必要はありません。リソースを破棄したり、メモリを管理したりする方法を使用します。
上記の回答における Seabizkit の懸念は非常に正当なものだと思います。ここに引用されています:
@DanHerbert 2つのスレッドがシングルトンを呼び出すとどうなりますか..説明させてください...オブジェクトにロックがあります..スレッドセーフにするために。つまり、ard1 呼び出しが webInstance にアクセスすると、スレッド 2 はスレッド 1 が終了するのを待機します。またはインスタンスを作成するためだけのロックです。発信者が 10 人いるとします....ロックは連鎖していることを意味しますか...または非同期です。私が求めているものが得られると思います。– Seabizkit 13 10月. 162016-10-13 10:01 <
いくつかのテストを行った後、単一の「クライアント」オブジェクトが複数の異なるスレッドで使用されている場合、良好なパフォーマンスが得られないことがわかります。10 個のスレッドが作成され、それらすべてが同じシングルトン「クライアント」を使用している場合、以前のすべての呼び出しが完了するまで順番に待機する必要があります。
その証拠を確認するには、こちらの c-sharp コーナー記事のサンプルを読んで実行してください: https://www.c-sharpcorner.com/article/increase-performance-with-an-object-pool-or-why -singleton-may-cause-performance/ タイトルは「オブジェクト プールを使用してパフォーマンスを向上させる、またはシングルトンがパフォーマンスの問題を引き起こす可能性がある理由」。
シングルトン Web サービス ユーザーのバブルを破裂させて申し訳ありません。また、Web サービス クライアントがシングルトンに「ケージ」されている Microsoft の例を見つけるのは非常に難しいでしょう。