何时使用 FileChannel 读取（）/写入（）文件？

Question

I am reading the book Thinking in Java, which explains the java.nio.* package and says that NIO is faster than reading and writing files with traditional IO streams. Why?

I have reviewed the following information:

• IO stream is byte oriented, traditional IO processing unit is byte, and NIO processing unit is block (byte array), but I think traditional IO can also directly process block (byte array) through BufferedFile*, and traditional IO also has direct Method of processing byte array

  private native int readBytes(byte b[], int off, int len) throws IOException;

• IO is blocking read, NIO can be non-blocking, but I found that the file NIO can only be non-blocking, then NIO has no advantage.

• I think the need to use NIO is generally other advantages that need to use NIO, such as:

   transferTo()/transferFrom()

So, when should I use NIO for file reading and writing? Why is it faster than traditional IO? What is the correct way to use it? Should I use IO or NIO only when reading and writing files?

Answer 1

There are only two cases where a FileChannel is faster than a FileInputStream or FileOutputStream .

The first is when you can use an off-heap ("direct") ByteBuffer to hold data, so that it isn't copied into the Java heap. For example, if you were writing a web-server that delivered static files to a socket, it would be faster to use a FileInputStream and a SocketChannel rather than a FileInputStream and a SocketOutputStream .

These cases are, in my opinion, very few and far between. Normally when you read (or write) a file in Java you will be doing something with the data. In which case, you can't avoid copying the data onto the heap.

The other use for a FileChannel is to create a MappedByteBuffer for random access to the contents of a file. This is significantly faster than using RandomAccessFile because it replaces explicit calls to the OS kernel with memory accesses that leverage the OS's paging mechanism.

If you're just getting started with I/O in Java, I recommend sticking with the classes in java.io unless and until you can explain why switching to java.nio will give you improved performance. It's much easier to use a stream-oriented abstraction than a block-oriented one.