Java でのソケット プログラミングではいつ、InputStream.available()
または便利ですか?BufferedInputStream.available()
1 に答える
私の見解では、「見積もり」がどれほど優れているかがわからない限り、この方法は役に立ちません。また、ソケットに接続されたストリームの場合、すべてのケースで見積もりが信頼できるとは限りません。
問題は、メソッドの戻り値が、ソケットのストリームの終わりに達した場合と、ソケットで現在使用可能な文字がないが、さらに配信される可能性がある場合とを区別しないことです。javadoc によると、どちらもゼロを返す可能性があります。
この不確実性により、この方法はほとんど役に立たなくなります。
ソケットの場合 (および類似のケース) では、
available()
メソッドは、結果がゼロの場合に読み取るかどうかを実際には通知しません。そして、間違った選択をすると、意図しないときにブロックするか、ソケットが実際に閉じられたことをまったく発見できなくなります。どちらかが悪い可能性があります。それ以外の場合 (ローカル ファイルからの読み取りなど) には、読み取りがブロックされる可能性があるかどうかを調べる方法が他にもあります。その上、とにかく読み取りが長時間ブロックされる可能性は低いため、通常、ブロックを回避することにはあまり意味がありません。
最後に、場合によっては、ゼロ以外の応答を取得して、とにかく読み取り呼び出しをブロックすることができると思います。(私は、リモートにマウントされたファイル システム上のファイルについて考えています...そして、読み込もうとするとリモート サーバーがフリーズする可能性があります。)
肝心なのは、見積もりavailable()
を返すと文書化されていることです。javadoc は、考えられるすべての状況下でその推定値がどれほど信頼できるかを保証するものではありません。実際、状況によっては、リモート サーバーが何をしようとしているのかを知る必要があるため、推定値が正確でない場合もあります。