Java BufferedInputStream的幕后

Question

首先，我理解了缓冲作为包装的概念，例如，FileInuptStream充当从底层流读取内容的临时容器（让我们采取读取场景），在本例中-FileInputStream。

1. 比方说，有100个字节要从流中读取（文件作为源）。
2. 如果没有缓冲，代码（BufferedInputStream的读取方法）必须进行100次读取（一次一个字节）。
3. 使用缓冲，取决于缓冲区大小，代码使

在这种情况下，虽然被一个BufferedInputStream包装，底层流（例如FileInputStream）仍然必须一次读取一个字节。那么，缓冲的好处在哪里（不是对于只需要对缓冲区进行两次读取调用的代码，而是对于应用程序的性能）？

谢谢。

编辑：

我把它作为后续的“编辑”，而不是“评论”，因为我认为它在上下文中更适合这里和TL；为@Kayaman和我之间聊天的读者提供DR。

BufferedInputStream的读取方法说明（摘录）：

作为额外的便利，它尝试通过重复调用底层流的read方法来读取尽可能多的字节。此迭代读取将继续，直到以下条件之一变为真：

The specified number of bytes have been read,
The read method of the underlying stream returns -1, indicating end-of-file, or
The available method of the underlying stream returns zero, indicating that further input requests would block. 

我深入代码，发现方法调用跟踪如下：

1. BufferedInputStream-

以字节序列的形式读取子数组。

在BufferedInputStream中调用read1（#4，如上所述）处于无限for循环中。它返回上述read方法描述摘录中提到的条件。

正如我在OP（#6）中提到的，调用似乎是由一个底层流处理的，该流与API方法描述和方法调用跟踪相匹配。

问题仍然存在，如果FileInputStream的本机API调用-readBytes每次读取一个字节，并创建一个要返回的字节数组？

Answer 1

底层流（例如FileInputStream）仍然必须一次读取一个字节

幸运的是，这将是非常低效的。它允许的BufferedInputStream使读取（字节[8192]缓冲区）调用的FileInputStream将返回数据块。

如果您想要读取一个字节（或不读取），它将有效地从BufferedInputStream的内部缓冲区返回，而不必向下到文件级别。所以BI的存在是为了减少我们从文件系统进行实际读取的时间，当这些读取完成时，即使最终用户只想读取几个字节，它们也以有效的方式完成。

从代码中可以清楚地看出，BufferedInputStream。read（）不会直接委托给UnderlyingStream。read（），因为这将绕过所有缓冲。

public synchronized int read() throws IOException {
    if (pos >= count) {
        fill();
        if (pos >= count)
            return -1;
    }
    return getBufIfOpen()[pos++] & 0xff;
}