コードからメッセージ (警告、エラー、例外など) を受け取る ASP.NET C# シングルトン (HttpContext.Current.Session を介してセッションに範囲指定) があります。メッセージはコードの問題に関連しており、主に本番環境ではなくデバッグ中に使用されます。
このオブジェクトのカスタム デストラクタを作成して、その内容がディスク上のファイルとして書き込まれ、追加されるようにしました。
この状況に関連して、次の 2 つのことをお聞きしたいと思います。
a] オブジェクトのデストラクタ中にファイルを開いて書き込むのは良い考えですか? 並行 IO アクセスは、静的ロックによって処理されます。
b] セッション スコープ オブジェクトに対してデストラクタが呼び出されるのはいつですか? サーバーでセッションの有効期限が切れたときだけですか?
これを実現するには、IDisposableを実装し、ロガーのインスタンスをusingブロックにラップします。これにより、ロガーでdispose メソッドを呼び出すことが保証されます。
また、既存のロギング パッケージを使用することをお勧めします。あなたがこれを自分でやろうと決心した場合、そして将来のために心に留めておくだけです：
a) いいえ、それは良い考えではありません。ファイナライザ (デストラクタ) でマネージド リソースにアクセスするべきではありません。たとえば、メモリにログ文字列がある場合、それら (またはそれらが含まれているリスト) にアクセスすることはお勧めできません。この点。
推奨されるパターンを繰り返したくないので、https://stackoverflow.com/a/1943856/2586804を参照してください
管理中にアクセスする必要がある場所は 1 つだけであることがわかります。Disposeこれは、ユーザー コードによって呼び出され、GC ではない場合です。したがって、これを達成するには、.Dispose()自分自身を呼び出す (または a を使用してusing) 必要があるという結論に達するのに役立ちます。GC がそれを行う場合 (およびその場合) は、ログ行を含む管理対象メンバーにアクセスできません。
b）わかりませんが、とにかくこの目的でファイナライザーを使用できないため、問題ではありません。
肝心なのは、GC に頼ってコードを実行することはできないということです。いつ発生するかわからないため、悪い習慣です。さらに、現在または将来のどこかでオブジェクトへの参照があると、オブジェクトの収集が妨げられ、バグが発生します。
また、c# ファイナライザー/デストラクタにコードを実行させるべきではありません。これは、それが目的ではなく、マシンが使い果たされないようにアンマネージ リソースを解放するためのものだからです。また、C# でそれらを使用することはめったにないことに注意してください。これは、ほとんどの人が日常業務ですべてマネージド オブジェクトを使用しているためです。
オブジェクトにログを書き込むように明示的に指示する代わりに、呼び出されるメソッドFlushが適切な名前になります。または、一度に 1 行ずつ書き込みます。これは通常の動作になります。