FileInputStream 已经使用缓冲区了吗？
当我使用 FileInputStream 读取一个对象（比如几个字节）时，底层操作是否涉及：
1）读取整个磁盘块，这样如果我随后执行另一个读取操作，则不需要真正的磁盘读取是因为文件的该部分已在上次读取操作中获取？
或者
2) 发生新的磁盘访问，因为 FileInputStream 不做任何缓冲，而应该使用 bufferedInputStream 来实现 (1) 的效果？
我认为由于 FileInputStream 使用 read 系统调用并且它仅从硬盘读取一组页面，因此必须进行一些缓冲。
When I am using FileInputStream to read an object (say a few bytes), does the underlying operation involve:
1) Reading a whole block of disk so that if I subsequently do another read operation, it wouldnt require a real disk read as that portion of the file was already fetched in the last read operation?
OR
2) A new disk access to take place because FileInputStream does not do any buffering and bufferedInputStream should have been used instead to achieve the effect of (1)?
I think that since the FileInputStream uses the read system call and it reads only a set of pages from hard disk, some buffering must be take place.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
FileInputStream将进行底层本机系统调用。大多数操作系统都会为此进行自己的缓冲。因此它不需要对每个字节进行真正的磁盘寻道。但是，您仍然需要支付本机操作系统调用的成本，这是昂贵的。所以 BufferedStream 会更好。但是，对于读取少量数据（如您所说，几个字节甚至 kB），任何一种都应该没问题，因为操作系统调用的数量不会有太大不同。FileInputStreamwill make an underlying native system call. Most OSes will do their own buffering for this. So it does not need a real disk seek for each byte. But still, you have the cost of making the native OS call, which is expensive. So BufferedStream would be preferable. However, for reading small amounts of data (like you say, a few bytes or even kBs), either one should be fine as the number of OS calls won't be that different.FileInputStream 的本机代码位于此处：看起来那里没有任何缓冲。操作系统缓冲可能会启动，但没有明确的指示是否/何时发生这种情况。
Native code for FileInputStream is here: it doesn't look like there is any buffering going on in there. The OS buffering may kick in, but there's no explicit indicator one way or another if/when that happens.
需要注意的一件事是通过慢速连接从已安装的网络卷中读取数据。我为此使用非缓冲 FileInputStream 遇到了很大的性能问题。在开发中没有发现它，因为文件系统是本地的。
One thing to look out for is reading from a mounted network volume over a slow connection. I ran into a big performance issue using a non-buffered FileInputStream for this. Didn't catch it in development, because the file system was local.