GC.SuppressFinalizeはパフォーマンスの問題を引き起こす可能性がありますか？

GC.SuppressFinalizeの唯一の目標は次のとおりです。

ファイナライザーが管理されていないリソースを解放しないようにするIDisposable.Disposeの実装によってすでに解放されています。

出典：MSDN

オブジェクトを破棄したら、に示すように、GC.SuppressFinalize(this);を呼び出す必要があります。 GC.SuppressFinalize（）はいつ使用する必要がありますか？ “。コード分析 “ CA1816 ルールも役立ちます。

現在、IDisposableを実装しています管理されていないリソースを持たないオブジェクトは、非常に奇妙で疑わしいように見えます。その人があなたに与えた唯一の理由は、IDisposable特定のケースで何かを改善しますが、実際にそれを行う理由はありません。

パフォーマンスの問題を引き起こしますか？言うのは難しいです：特定のケースに依存します。

もちろん、他の問題が発生しますか？もちろん、IDisposableの実装が面倒であるという事実を考慮しないと、この方法を使いすぎると、コードが読み取れなくなり、維持できなくなります。

public int ComputePrice(Rebate rebate) { using (var currentCurrency = this.User.FindCurrency()) { using (var priceWithoutRebate = this.GetPurePrice()) { using (var canApplyRebate = rebate.CanApplyTo(this)) { if (!canApplyRebate) { return priceWithoutRebate; } using (var priceWithRebate = priceWithoutRebate.Apply(rebate)) { return priceWithRebate; } } } } } 

コメント

• 話は、昔、彼らには何らかのつながりがあったということだと思います/おそらく接続/コマンドのADO.NETコードのリークが原因で、ストリームリークの問題が発生し、これにより大量のリソースリークが発生しました。すべてにIDisposableを実装することで問題が解決することを知っていたので、問題は解決しました。ほとんどのオブジェクトに実装する必要があります。
• @AndrewHoffman：もっともらしい説明のようです。しかし、それでも'現在の慣行を正当化するものではありません。

IDisposableクラスで重い（「痛みを伴う」）Dispose + Finalizerパターンを使用する必要はありません。 if クラスは封印されており、クラスには管理されていないリソースはありません。

そのような状況では、パブリックDispose()にはファイナライザーがなく、クラスは封印されています。

クラスを封印する理由は、「子クラスに管理されていないリソースがある場合はどうなるか」という問題を回避するためです。および「将来、子クラスに管理されていないリソースがある場合はどうなりますか？」

以前MicrosoftのJoeDuffyが、、およびすべての順列サブセットの実装。

この記事の寄稿者には、Herb Sutter、Brian Grunkemeyer、Jeff Richter、およびその他のC＃の著名人が含まれます。この記事は、MSDNに掲載されているものよりもはるかに詳細です。

残念ながら、Joe Duffyの新しいブログエンジンは2005年の元の記事をうまく保存できていないため、多少混乱しているように見えます。リンクは次のとおりです： http://joeduffyblog.com/2005/04/08/dg-update-dispose-finalization-and-resource-management/

JoeDuffyの記事全体を含むMS-Wordドキュメントをもっとうまく添付できたらいいのにと思います フォーマット。 🙁