0

これが単純な設計上の質問であることを願っています。

コンテクスト：

ソケット接続を介して1つから多数のファイルをダウンロードしている可能性があります。byte[]それらがソケットから読み取られるときに、私は渡されます。また、それらのバイトを書き込むファイルも知っています。これらのバイトを。でファイルに追加していますFileOutputStream。ファイルのすべてのバイトが受信されたときにも通知されます。

質問：

次の方が良いですか：

  1. FileOutputStreamすべてbyteが受信され、書き込まれるまで開いたままにします
  2. FileOutputStream受信時に適切なファイルにsを追加する新しいファイルを開き、byte毎回閉じます。

2は、ダウンロードのいずれかで問題が発生した場合（何らかの理由でバイトの取得を停止した場合など）に備えて、書き込みのたびにストリームを閉じるため、私にとっては安全だと感じています。しかし、それはあまり効率的ではないようです。開閉FileOutputStreamの費用がどれだけ高いかわかりません。FileOutputStreamいつ閉じるかを知るために必要な特別な注意以外に、開いたままにしておくことに対する他の副作用はありますか？

前もって感謝します。

4

2 に答える 2

1

ファイルを 100 回または 1000 回再オープンするのにかかる時間を計測することで、ファイルの再オープンにかかるコストをテストできます。

私のマシンでは約 2.1 ミリ秒かかるため、750 KB/秒以上の場合、ファイルのダウンロードが遅くなる可能性があります。

不完全なファイルを持っている場合、それをそのままにしておきますか、それともファイルが破損していることを知りたいですか、または正しくダウンロードできない場合は削除しますか?

于 2012-12-18T15:50:24.133 に答える
0

2の方が安全ですが、1よりもはるかに高価であることに同意します。

FileOutputStreamを作成するたびに、ネイティブに実装されたopen（）メソッドが呼び出されます。このメソッドを実装すると、ファイルハンドルが作成され、オペレーティングシステムに対してopen（）システムコールが発行されます。これには、少なくとも同期（OSレベルでのファイル作成は通常アトミックです）とおそらくある程度のバッファー割り当てが含まれるため、ファイルハンドルを開いたままにするよりもはるかにコストがかかります。

一方、1を使用すると、開いているファイルハンドルが多すぎて制限に達するリスクがあります（これは、基盤となるオペレーティングシステムによって異なります）。また、すべてのエラーパスを制御していない場合は、ファイルを閉じないこともできます。

並行して開く開いているファイルの数、ファイルを閉じるためにすべてのエラーパスを制御するのがどれほど難しいか、サーバーに必要なスループットを評価することをお勧めします。そのような分析の結果に応じて、私は1または2に行きます。

さらに、1を使用する場合は、タイムアウトのために書き込まれていないファイルを閉じるウォッチドッグなど、いくつかのセーフネットを実装できます。

于 2012-12-18T16:00:31.587 に答える