定期的にデータをファイルに保存しています（毎回ファイルを開いたり閉じたりしています）、ファイル操作にかかる時間をStopwatchで測定したいと思います。ストリームを閉じるとスレッドがブロックされますか？
Close()の測定時間に含めるべきですか？
私はソフトウェアに問題があり、ファイルの操作が疑わしいです。ビジーなHDDや何らかの障害が発生して遅延の原因となることがあります。この場合、Close()を呼び出すと遅延（ブロッキング）が発生するか、またはブロックされていない方法（フレームワーク/ winapiファイルの深いところがライトバッファなどからフラッシュされています）がClose()ですか？
Write()が失敗すると遅くなるでしょうか？私は、何が起こるかを素早くテストするためにディスクの問題をどのようにシミュレートするのか分かりません。
まず、the documentation for FileStreamはCloseではなくDisposeを呼び出すことをお勧めします。参照元の確認、Closeが行うすべては次のとおりです。
Dispose(true);
GC.SuppressFinalize(this);
が（ブロッキング）遅延が発生し、この場合、（）閉じるを呼び出すか、閉じる （）非ブロック方式（しかし、どこか心の奥底 ありますフレームワーク/ winapiファイルは、 の後に書き込みバッファなどからフラッシュされていますか？ 2つのことを行い
Close通話Dispose、：
もちろん、「保留中の書き込みをディスクに書き込む」とは、OSに「保留中の書き込みをディスクにフラッシュする」ことを意味します。 OSは、さまざまな要因（たとえば、USBドライブの書き込みが遅くなる傾向があり、一時ファイルが決してディスクにフラッシュされないなど）によって処理方法が異なります。
私のdownvoteではありませんが、あなたは私の質問に答えていません。「Close」を呼び出すと呼び出し元がブロックされますか（「いいえ」と言っている気がしますか？ @HansPassantコメントは、問題の場合に 'Write'が呼び出し元をブロックすることを説明しています。 – Sinatr
ファイルのクローズに要する時間が短すぎて問題になるか、そうでないかのいずれかです。どのようにそれらを測定せずに真であるかを見つけることを計画していますか？ –
意味のある測定値を得ることはできません。ディスクに直接書き込むことはなく、ファイルシステムのキャッシュに書き込むことになります。非常に高速なメモリー間コピー。ファイルを閉じた後、ずっと遅く、ディスクに書き込まれます。これは間違っている可能性があります。ファイルシステムのキャッシュがいっぱいになると起こります。あまりにも多くの書き込みをするか、または他のプログラムが行うか、またはマシンに十分なRAMがないか、ディスクが遅すぎるか断片化しているためです。スペースが解放されるまでWrite（）はブロックされますが、それには時間がかかります。非常にランダムで、予測が非常に難しい。 –
メッセージが書き込まれるたびにファイルをオープン/クローズするようにロガーを設定したところ、非常に奇妙な問題が明らかになりました。この場合、ログファイルサイズに比例してメッセージを書き込む時間です。場合によっては、単一のメッセージを書くのに0.3秒かかった。 FileStreamをすぐに開くと、パフォーマンスが大幅に向上しました（ファイルサイズに依存せず、メッセージを書き込む時間が一定になりました）。だから私はファイルのオープン/クローズ操作がデフォルトで同期していると思う（私は.NET 5には非同期アナログがあると聞いた）。ですから、このファイルが必要なことがよく分かっている場合は、それを開いたままにしておくことをお勧めします。 –