Is FileInputStream already using buffers?

Question

When I use FileInputStream to read an object (say, several bytes), does the basic operation do:

1) Read the entire disk block, so that if I subsequently do another read operation, this does not require reading the real disk, since this part of the file has already been extracted in the last read operation?

OR

2) New disk access because FileInputStream does not do any buffering, and should bufferedInputStream be used instead to achieve effect (1)?

I think that since FileInputStream uses the read system call and it only reads a set of pages from the hard drive, some buffering needs to be done.

Answer 1

FileInputStream will create the main system call. Most operating systems will do their own buffering for this. Thus, for each byte, the search for a real disk is not required. But still, you have the cost to make a call on your native OS, which is expensive. Thus, a BufferedStream would be preferable. However, to read small amounts of data (for example, a few bytes or even kB), each of them must be accurate, since the number of calls to the OS will not differ.

Answer 2

The source code for FileInputStream is here : it doesn't look like buffering is going on there. OS buffering can hit, but there is no explicit pointer anyway if / when it happens.

Answer 3

One thing you need to pay attention to is reading from a mapped network volume over a slow connection. For this, I ran into a big performance problem, using the unbuffered FileInputStream for this. I did not catch it in development because the file system was local.