私はjavanioパッケージを学んでいましたが、Fileによってすでに提供されているメソッドがたくさんあり、nio.FilesがPathクラスを使用して再び提供していることに気付きました。その数のように私は得た。私は実際にnioパッケージの実際の使用法を理解していません。
私はこのパッケージに非常に慣れていないので、私の質問は間違っているかもしれませんが、少しの助けが私をさらに読むように後押しすることができます。
私はjavanioパッケージを学んでいましたが、Fileによってすでに提供されているメソッドがたくさんあり、nio.FilesがPathクラスを使用して再び提供していることに気付きました。その数のように私は得た。私は実際にnioパッケージの実際の使用法を理解していません。
私はこのパッケージに非常に慣れていないので、私の質問は間違っているかもしれませんが、少しの助けが私をさらに読むように後押しすることができます。
Java プログラミングでは、I/O は最近までストリーム メタファを使用して実行されていました。すべての I/O は、Stream と呼ばれるオブジェクトを介して一度に 1 バイトずつ移動するものと見なされます。ストリーム I/O は、外部との通信に使用されます。また、オブジェクトをバイトに変換してからオブジェクトに戻すために、内部的にも使用されます。
NIO は元の I/O と同じ役割と目的を持っていますが、ブロック I/O という別の比喩を使用しています。java.nio (new/non-blocking I/O) ) API は JDK1.4 で導入されました。
ストリーム I/O とブロック I/O の違いは何ですか?
ストリーム指向の I/O システムは、一度に 1 バイトずつデータを処理します。入力ストリームは 1 バイトのデータを生成し、出力ストリームは 1 バイトのデータを消費します。ストリーミング データのフィルターを作成するのは非常に簡単です。また、複数のフィルターをチェーン化して、それぞれが単一の高度な処理メカニズムでそれぞれの役割を果たせるようにすることも比較的簡単です。反対に、ストリーム指向の I/O はかなり遅いことがよくあります。
ブロック指向の I/O システムは、ブロック単位でデータを処理します。各操作は、1 つのステップでデータのブロックを生成または消費します。ブロック単位でデータを処理すると、(ストリーミングされた) バイト単位で処理するよりもはるかに高速になります。ただし、ブロック指向の I/O には、ストリーム指向の I/O の優雅さと単純さが欠けています。
どのような場合に java.io を使用する必要があり、どのような場合に java.nio を使用する必要がありますか?
スケーラビリティによって、おそらくパッケージの選択が促進されます。java.net は、ソケットごとに 1 つのスレッドを必要とします。コーディングが大幅に簡単になります。java.nio ははるかに効率的ですが、コーディングが困難です。
数万の接続を処理すると、スケーラビリティが向上する可能性がありますが、数が少ない場合は、ブロック IO でスループットが向上する可能性があります。
SSL を使用する場合、java.nio は簡単に処理できるものではありません
重要 : いずれかのパッケージを使用している場合、やむを得ない理由がない限り、フレームワークをゼロから作成することはお勧めできません。
java.nio の場合、Grizzly や Quick Server などのプロジェクトは、再利用可能なノンブロッキング サーバー コンポーネントを提供します。
java.nioの問題点
最終的には、プロジェクトの特定の要件と達成しようとしているものに要約されます。最良のソリューションの中には、最も複雑なインフラストラクチャをまったく必要としないものもあります。
更新 : jdk 1.7 以降に存在する NIO.2 パッケージについて最近知りました。NIO.2 は NIO とは異なります。主な点は、NIO.2 が非同期チャネル機能を提供することです。NIO.2 プライマー
NIO を使用している場合は、違いを確認する価値があり、どちらが目的に合っているかを確認してください。
のほとんどすべてのメソッドにjava.io.File
は、互換性の理由で修正できない問題があります。最も明白なのは、メソッドboolean
が失敗したときに a を返すことです。これらの問題に加えて、プラグイン可能なファイル システムをサポートしたいという要望や、その他多くのことが原因で、まったく新しいファイル システム API の開発が必要になったため、java.nio.File
が作成されました。