FileInputStream 已经使用缓冲区了吗？答案

【问题标题】：Is FileInputStream using buffers already?FileInputStream 已经使用缓冲区了吗？
【发布时间】：2011-11-17 06:32:08
【问题描述】：

当我使用 FileInputStream 读取一个对象（比如几个字节）时，底层操作是否涉及：

1) 读取整个块磁盘，这样如果我随后执行另一个读取操作，它就不需要真正的磁盘读取，因为文件的该部分已在上次读取操作中获取？

或

2) 因为FileInputStream 没有做任何缓冲，而应该使用bufferedInputStream 来实现新的磁盘访问，以达到(1) 的效果？

我认为，由于 FileInputStream 使用 read 系统调用，并且它只从硬盘读取一组页面，因此必须进行一些缓冲。

【问题讨论】：

我对底层 OS IO 的了解不足以回答，但缓冲并不是避免多次调用的唯一原因。每个读取操作还涉及对本机方法的调用，这会产生一些开销。因此，减少本机方法调用的数量也很有用。
尝试一个简单的基准测试。您可能会注意到改进。

标签： java io disk fileinputstream

【解决方案1】：

FileInputStream 将进行底层本机系统调用。大多数操作系统会为此做自己的缓冲。所以它不需要为每个字节进行真正的磁盘查找。但是，您仍然需要进行本机操作系统调用的成本，这是昂贵的。所以 BufferedStream 会更好。但是，对于读取少量数据（如您所说，几个字节甚至 kB），任何一个都应该没问题，因为操作系统调用的数量不会那么不同。

【讨论】：

【解决方案2】：

FileInputStream 的本机代码是here：看起来那里没有任何缓冲。操作系统缓冲可能会启动，但如果/何时发生这种情况，并没有明确的指示。

【讨论】：

感谢编码器参考。似乎 L65 和 L70 是相关的。你知道 readSingle() 是在哪里实现的吗？这不是系统调用。

【解决方案3】：

需要注意的一点是通过慢速连接从已安装的网络卷中读取。为此，我使用非缓冲 FileInputStream 遇到了一个很大的性能问题。在开发中没有发现它，因为文件系统是本地的。

【讨论】：