[入力|出力] ストリームは JDK1.0 から存在し、文字に対応するリーダー|ライターは JDK1.1 から存在します。
ほとんどの概念は類似しているように見えますが、1 つの例外があります。ストリームの基本クラスは、一度に1バイトを処理する抽象メソッドを宣言しますが、基本リーダー/ライタークラスは、配列全体を処理する抽象メソッドを宣言しますchar。
したがって、私が正しく理解していれば、オーバーライドされたすべてのストリームクラスは 1 バイトの処理に制限されます (したがって、各バイトに対して少なくとも 1 つのメソッド呼び出しを実行します!)。一方、オーバーライドされたリーダー/ライターは、配列 (-buffer) ごとのメソッド呼び出しのみを必要とします。
それは大きなパフォーマンスの問題ではありませんか？
InputStreamストリームをまたはのサブクラスとして実装できますが、配列OutputStreamに基づくことはbyteできますか?
実際には、InputStream のサブクラスは、一度に 1 バイトを読み取るメソッドをオーバーライドする必要がありますが、バイト配列を読み取りながら他のメソッドをオーバーライドすることもできます。ほとんどの入力/出力ストリームに実際に当てはまると思います。
したがって、私の意見では、これはパフォーマンスの問題ではありません。はい、入力/出力ストリームを拡張して、バイト配列に基づくことができます。
ほとんどの場合、1 バイトの読み取りは大きなパフォーマンスの問題です。しかし、InputStream の API ドキュメントを読むと、read() をオーバーライドする必要があることがわかりますが、read(byte[],int,int) もオーバーライドする必要があります。とにかく、あらゆる種類の InputStream を使用するほとんどのコードは、配列スタイルのメソッドを呼び出しますが、その関数のデフォルトの実装は、すべてのバイトに対して read() を呼び出すことによって実装されるだけなので、パフォーマンスに悪影響を及ぼします。
OutputStream についても同じことが言えます。
Readers/は、 Unicode 文字などの 1 バイト以上Writersで構成される文字を読み取るためのものであることに注意してください。一方、ストリームは、文字列以外の (バイナリ) データを扱う場合により適しています。
InputStreamそれとは別に、OutputStreamバイト配列全体を読み書きするメソッドもあります。
ダニエルが言ったようread()に、クライアントはそれを直接使用する可能性があるため、オーバーライドする必要がありますが、オーバーライドする必要もありますread (byte[],int,int)。
ただし、jvm はそのメソッドをインライン化できるため、パフォーマンスを気にする必要があるかどうかは疑問です。何よりも、それは私には問題に思えません。
また、ほとんどのリーダーは背後でいくつかの基本的な入力ストリームを使用するため、いずれにせよ、これらの文字配列ベースのメソッドは最終的に呼び出すread(byte[],int,int)か、read()直接呼び出すことになります。
パフォーマンスに関しては、BufferedInputStream でラップすると、JVM はシングル バイトの read メソッド呼び出しのオーバーヘッドを最適化できるはずです。つまり、バッファリングを自分で行うのと同じくらい高速です。