BufferedInputStream buffered IO and read (byte [] b) in InputStream

InputStream
InputStream is the top-level class of all input streams, of course only defined, not implemented, the specific implementation by subclasses, such as AudioInputStream, ByteArrayInputStream, FileInputStream, etc.
It indicates the implementation of inputStream's read (byte [], int off, int len), which is simply to call the read () method, and the read () method is to read only one byte at a time, and still call it every time. The underlying system, so InputStream read (byte [], int off, int len) performance is the same as calling read () directly, byte [] buffer is here. Therefore, it is recommended that subclasses provide a better way to override the read (byte [], int off, int len) method.
The
two read () methods of FileInputStream are implemented in local methods, because FileInputStream interacts with the underlying operating system, and there is no better and easier performance than using local methods. Therefore, the recommendations in the third paragraph are adopted here, and the cache function is truly implemented, although we do not know how to implement it.
So now that FileInputStream has implemented caching to improve performance, what is BufferedInputStream used for?
BufferedInputStream
adds some functionality to another input stream, namely buffered input and the ability to support mark and reset methods. When creating a BufferedInputStream, an internal buffer array is created. When reading or skipping bytes in the stream, the internal buffer can be filled again from the included input stream as needed, with multiple bytes at a time. The mark operation records a certain point in the input stream, and the reset operation causes all bytes read since the last mark operation to be read again before fetching new bytes from the included input stream.

In fact, the "buffered input" mentioned above does not really use the local method to improve performance like FileInputStream, but means that on this basis, for the convenience of programmers, a buffer (byte [1024 * 8] is provided internally buf), and decorated the FileInputStream class (when constructing BufferedInputStram must provide the decorated InputStream can be seen).
When using FileInputStream, read () reads a byte from the bottom, read (byte [], int off, int len) reads len-off bytes at a time, we need to provide a byte [] To store,
and when using BufferedInputStream, its read () is actually the same as read (byte [], int off, int len), internally it calls read (byte [], int off, int len) of FileInputStream that constructs the input Method, read the underlying data into byte [], and byte [] does not need us to provide, the class itself defines a byte [] buf array to store these data, so if you use BufferedInputStream our program does not need to For byte [] array operations, just write it like this:

FileInputStream fis=new FileInputStream("d:\\a.txt");  
BufferedInputStream bis=new BufferedInputStream(fis);  
int data=0;  
while((data=bis.read())!=-1){  
    //......          
}  

In this way, although one byte is read at a time, instead of reading data from the bottom layer every time, the underlying system is called at a time to read up to buf.length bytes into the buf array, and then read one byte from buf , Reducing the overhead of frequent calls to the underlying interface.
If the read (byte [], int off, int len) of BufferedInputStream is used, the buffer will be served by the incoming byte [] (although buf is sometimes used internally, but the performance is shown by the incoming byte [] to buffer).

Having said so much, should I use FileInputStream or BufferedInputStream if I want to buffer it? Going back to the purple text above, BufferedInputStream does not mainly provide buf, but encapsulates buffering and mark / readback functions. If you don't need to use the mark / readback function, and don't operate the buffer array in the middle, it is obvious that using FileInputStream's read (byte [], int off, int len) directly is the most efficient.

Finally, why use buffering performance is better, because the application can write multiple bytes to the underlying output stream (native read (byte)), without having to call the underlying system for each byte write (native read ()). The principle of OutputStream is basically the same, so I won't talk about it here.

Published 16 original articles · praised 0 · visits 844

Guess you like

Origin blog.csdn.net/weixin_45830683/article/details/103101471