これは技術的な問題というより良心の問題です:p サーバーからファイルをダウンロードするための Java コードを書いています...そのために、BufferedOutputStream メソッドの write() と BufferedInputStream メソッドの read() を使用しています。 .
だから私の質問は、バイトを保持するためにバッファを使用する場合、読み取るバイト数はいくつですか? 確かに、int byte = read() と write(byte) だけを使用してバイトからバイトを読み取ることができます。または、バッファーを使用することもできます。2 番目のアプローチを取る場合、毎回読み取り/書き込みするバイト数を定義するときに注意しなければならない側面はありますか? この数はプログラムにどのような影響を与えますか?
ありがとう
非常に高速なネットワーク接続がない限り、バッファのサイズはほとんど影響しません。少し大きなバッファを使用しても害はありませんが、4k バッファで問題ないと思います。
同じことがおそらく using と ... を使用していると仮定して適用さread()れread(byte[])ますBufferedInputStream。
非常に高速/低遅延のネットワーク接続がない限り、ネットワークとコンピューターのネットワーク インターフェイスが維持できるデータ レートがボトルネックになります。典型的なインターネット接続の場合、アプリケーションは、ネットワークよりも 2 倍以上の速さでデータを移動できます。したがって、ばかげたことをしない限り (バッファリングされていないストリームで 1 バイトの読み取りを行うなど)、Java コードがボトルネックになることはありません。
BufferedInputStream と BufferedOutputStream は通常、その実装を System.arraycopy に依存しています。System.arraycopy にはネイティブ実装があり、memmove または bcopy に依存している可能性があります。コピーされるメモリの量は、バッファ内の使用可能なスペースによって異なりますが、ネイティブ コードに至るまでの実装は非常に効率的であり、読み取り/書き込みのバイト数に関係なく、アプリケーションのパフォーマンスに影響を与える可能性はほとんどありません。
ただし、BufferedInputStream に関しては、上限の高いマークを設定すると、新しい内部バッファーの作成が必要になる場合があります。マークを使用する場合、古いバッファで使用できるよりも多くのバイトを読み取ると、パフォーマンスが一時的に低下する可能性がありますが、償却されたパフォーマンスは依然として線形です。
Stephen C が述べたように、ネットワークが原因でパフォーマンスの問題が発生する可能性が高くなります。
ネットワーク接続の MTU (最大トラフィック ユニット) はいくつですか? たとえば、UDP を使用している場合は、この値を確認して、より小さいバイト配列を使用できます。これが基準にならない場合は、メモリがプログラムをどのように消費するかを確認する必要があります。1024 - 4096このデータを保存して引き続き受信するには、良いバリアントになると思います