许多嵌套的BufferedInputStream - 有什么影响？

Question

有一个共同的模式，当每个应用程序层处理来自流的数据往往将其包装到BufferedInputStream中时，总的来说，有很多缓冲区，从缓冲区填充，从缓冲区填充等等。

我认为这是不好的做法，并且想要质疑：它如何影响性能？这会导致错误吗？

Answer 1

这是一个非常普遍的问题，但我想说有很多层缓冲输入流（用任何语言）都有很多问题。

• 每个缓冲区占用内存，即使它没有被填充。因此，即使数据直接被吸收到顶层“层”，内存仍然在不必要地使用。 （注意：我假设Java没有自动调整其缓冲区或任何东西 - 我不是Java专家。）
• 每当您从顶级缓冲区读取时，您将启动一大串方法调用。方法调用涉及间接（即指针跟踪），数据传递（这可能导致缓存性能不佳），等等。
• 这可能意味着设计没有经过深思熟虑，因为缓冲流通常应该用于从实际需要缓冲的源读取，如磁盘或网络。

关于此事的几点想法。我相信拥有更好Java知识的人可以提供更详细的分析。

Answer 2

由于额外的缓冲区，它会增加内存占用，但我怀疑它很少见，因为它可能会对给定的程序产生重大影响。这是在您需要之前不尝试优化的标准规则。

Theres也必然是一个轻微的处理器开销，但这将更不重要。

这一切都取决于它的使用量，如果有很多大型链条可能会出现问题，但我认为这不太可能是一个问题。

正如大卫所说，它很可能表明设计不佳。组件能够直接共享更复杂的对象可能更有效，但这一切都归结为具体用途（而且我很难想到一个原因）您将以这种方式使用多个缓冲流。）

Answer 3

这确实是非常糟糕的做法，确实可能导致错误。如果方法A进行了一些读取，然后将流传递给附加BufferedInputStream并进行更多读取的方法B，则BufferedInputStream将填充其缓冲区，这可能会消耗方法A在方法B返回时期望仍然存在的数据。方法B的BufferedInputStream提前读取数据可能会丢失。

关于开销，实际上，如果读/写足够大，无论如何都会绕过中间缓冲区，因此没有你想象的那么多的额外复制：性能影响主要是额外的内存空间加上额外的方法调用。