4

プロセスに関する情報をプログラムでログインしているファイルがあるとします。通常のデバッグConsole.WriteLineに似ていますが、テストするコードの性質上、書き込むコンソールがないため、ファイルのような場所に書き込む必要があります。私の現在のプログラムは、このタスクにSystem.IO.StreamWriterを使用しています。

私の質問は、StreamWriterを使用するためのアプローチについてです。1つのStreamWriterインスタンスだけを開き、すべての書き込みを実行し、プロセス全体が完了したらそれを閉じる方がよいでしょうか。または、新しいStreamWriterインスタンスを開いてファイルに行を書き込み、すぐに閉じて、何かを書き込む必要があるたびにこれを行う方がよいでしょうか。後者のアプローチでは、これはおそらく、メインプロセスコードを過剰な行数で肥大化させるのではなく、特定のメッセージに対してそれを実行するメソッドによって容易になります。しかし、その実装を支援する方法があるからといって、必ずしもそれがより良い選択になるとは限りません。どちらかのアプローチを選択することに大きな利点はありますか?それとも、機能的に同等であり、プログラマーの肩に選択肢を残していますか?

4

3 に答える 3

4

事前にロールされたロギングの実装を見てください。彼らはあなたに多くの頭痛を救うかもしれません。明らかに、ストリームを開いたままにしておくと、クラッシュした場合に最終データの一部が失われる可能性がありますが、IOをさらにバッファリングすることでパフォーマンスが向上する可能性があります。一部の実装では、スプーラ/キューからの非同期ロギングなどの機能も提供される場合があります。

于 2010-04-22T15:38:22.017 に答える
1

書き込みごとに新しいStreamWriterを繰り返し開いたり閉じたりすると、GCに多くのリソースが生成され、開く操作ごとにファイルが実際に検索されるため、アプリにオーバーヘッドが発生します。一方、単一のストリームを開いたままにすると、ファイルのロックが保持されます。ですからそれは状況次第です。

ロギングメカニズムがパフォーマンスのボトルネックになることは望ましくないため、単一のストリームに書き込みます。重要なデバッグのために、バッファリングを解除するか、自動フラッシュします(ただし、パフォーマンスにも影響することに注意してください)。

log4netのモデルに従い、静的ログストリームを作成して、そのシングルトンに書き込みます。とにかくlog4netを調べて、自分でロールしないようにしてください。http://logging.apache.org/log4net/index.html

于 2010-04-22T15:39:41.140 に答える
1

データをバッファリング/キューに入れ、しきい値に達したらファイルに書き出し、アプリケーションが正常に終了/終了するとキュー全体をフラッシュします。

これに関する唯一の問題は、アプリケーションがクラッシュした場合、キュー内のアイテムが失われる可能性があることです...

HTH。

于 2010-04-22T15:41:30.870 に答える