Let me answer you questions one by one.
As far as I know, MappedByteBuffer has several benefits, such as:
It map the user space memory address to the kernel space memory address, so that it avoids memory copy from kernel space to user space while reading from file
After the first read of a piece in the file (etc an offset from 0 to 100 in the buffer), this piece would be cached in the memory, so when the second time you read the same piece from the buffer, you are reading it from the memory directly but not from the disk.
Your statements are not invalid.
Though, it is important not miss simple fact. Access of file data are always involving cache (except when it does not). In case of memory mapping pages from cache are mapped to your address space, with FileChannel extra memory copy involved.
If my understanding is correct, when you read the piece just once (never read it again so it would not read it from the memory), is it the same by using FileChannel.read(buffer, position) and using MappedByteBuffer.get(byte[], offset, length)?
No, FileChannel.read(buffer, position) involves extra memory copy. Data are going to hang in cache for some time anyway.
For the random accessing to a file (not read the same piece repeatedly), is FileChannel would be more efficient because MappedByteBuffer would take the memory it map while FileChannel need no memory?
Your reasoning is incorrect. With either data access pattern, FileChannel does extra memory to memory copy, MappedByteBuffer doesn't.
In addition, memory mapping is essentially lazy. Data is loaded from disk only when you are accessing corresponding memory page.
What's difference between I use a MappedByteBuffer and I simply load the whole file into my memory. The benefit of MappedByteBuffer is that it use a memory outside the JVM heap so no GC concern?
You can map a file orders of magnitude larger than physical memory on your box (single MappedByteBuffer is limited to 2GiB, so multiple mappings would be required). A page of file data access though mapping could be taken back by OS at any moment.
As far as GC is concerned, indeed, MappedByteBuffer does not occupy heap.
What to chose between FileChannel and MappedByteBuffer?
Using memory mapped data has other nasty implication.
- Any access to data in memory could become an IO operation (if the memory page is not cached). I.e. every ByteBuffer.get() call is potentially blocking.
- MappedByteBuffer cannot be disposed. Memory mapping will stay active until cleaned by GC.
That makes MappedByteBuffer an exotic and rarely used way to access data.
If would advise you to avoid MappedByteBuffer if
- Your application is interactive and response time is important.
- You are actively using multiple threads to process data (single thread stuck on IO may cause cascading blocking by other threads).
- You want non-blocking file IO
