使用 FileInputStream 时如何确定理想的缓冲区大小？
我有一种从文件创建 MessageDigest（哈希）的方法，我需要对很多文件（> = 100,000）执行此操作。我应该使用于从文件中读取的缓冲区有多大以最大限度地提高性能？
大多数人都熟悉基本代码（为了以防万一，我将在这里重复）：
MessageDigest md = MessageDigest.getInstance( "SHA" );
FileInputStream ios = new FileInputStream( "myfile.bmp" );
byte[] buffer = new byte[4 * 1024]; // what should this value be?
int read = 0;
while( ( read = ios.read( buffer ) ) > 0 )
md.update( buffer, 0, read );
ios.close();
md.digest();
最大化吞吐量的理想缓冲区大小是多少？我知道这是系统依赖的，我很确定它的操作系统、文件系统和硬盘驱动器依赖，并且可能还有其他硬件/软件混合在一起。
（我应该指出，我对 Java 有点陌生，所以这可能只是一些我不知道的 Java API 调用。）
编辑：我不提前知道这将用于哪种系统，所以我不能假设很多。 （出于这个原因，我使用 Java。）
编辑：上面的代码缺少诸如 try..catch 之类的东西以使帖子更小
最佳缓冲区大小与许多因素有关：文件系统块大小、CPU 缓存大小和缓存延迟。
大多数文件系统配置为使用 4096 或 8192 的块大小。理论上，如果您配置缓冲区大小以便读取比磁盘块多几个字节，则对文件系统的操作可能非常低效（即，如果您将缓冲区配置为一次读取 4100 个字节，每次读取需要文件系统读取 2 次块）。如果这些块已经在缓存中，那么您最终会付出 RAM -> L3/L2 缓存延迟的代价。如果你不走运并且块还没有在缓存中，那么你也要付出磁盘-> RAM 延迟的代价。
这就是为什么您会看到大多数缓冲区大小为 2 的幂，并且通常大于（或等于）磁盘块大小。这意味着您的一个流读取可能会导致多个磁盘块读取 - 但这些读取将始终使用完整块 - 不会浪费读取。
现在，这在典型的流式传输场景中偏移了很多，因为当您进行下一次读取时，从磁盘读取的块仍将在内存中（毕竟我们在这里进行顺序读取） - 所以你结束了在下一次读取时支付 RAM -> L3/L2 缓存延迟价格，而不是磁盘 -> RAM 延迟。就数量级而言，磁盘-> RAM 延迟非常慢，几乎超过了您可能正在处理的任何其他延迟。
因此，我怀疑如果您使用不同的缓存大小运行测试（我自己没有这样做），您可能会发现缓存大小对文件系统块大小的影响很大。除此之外，我怀疑事情会很快趋于平稳。
这里有大量的条件和例外——系统的复杂性实际上是相当惊人的（仅仅处理 L3 -> L2 缓存传输就非常复杂，而且它会随着每种 CPU 类型而变化）。
这导致了“现实世界”的答案：如果您的应用程序的 99% 存在，请将缓存大小设置为 8192 并继续（更好的是，选择封装而不是性能并使用 BufferedInputStream 隐藏细节）。如果您属于高度依赖磁盘吞吐量的 1% 的应用程序，请精心设计您的实现，以便您可以更换不同的磁盘交互策略，并提供旋钮和刻度盘以允许您的用户测试和优化（或提出一些自优化系统）。
是的，它可能取决于各种各样的东西——但我怀疑它会产生很大的不同。我倾向于选择 16K 或 32K 作为内存使用和性能之间的良好平衡。
请注意，您应该在代码中有一个 try/finally 块，以确保即使抛出异常也关闭流。
在大多数情况下，这真的没那么重要。只需选择一个合适的尺寸，例如 4K 或 16K 并坚持下去。如果您确定这是您的应用程序的瓶颈，那么您应该开始分析以找到最佳缓冲区大小。如果您选择的尺寸太小，您将浪费时间进行额外的 I/O 操作和额外的函数调用。如果你选择的尺寸太大，你会开始看到很多缓存未命中，这真的会减慢你的速度。不要使用大于 L2 缓存大小的缓冲区。
在理想情况下，我们应该有足够的内存在一次读取操作中读取文件。那将是最好的表现，因为我们让系统随意管理文件系统、分配单元和硬盘。实际上，您很幸运能够提前知道文件大小，只需使用向上取整为 4K 的平均文件大小（NTFS 上的默认分配单位）。最重要的是：创建一个基准来测试多个选项。
您可以使用 BufferedStreams/readers，然后使用它们的缓冲区大小。
我相信 BufferedXStreams 使用 8192 作为缓冲区大小，但就像 Ovidiu 所说，您可能应该对一大堆选项进行测试。它真的将取决于文件系统和磁盘配置来确定最佳大小。
使用 Java NIO 的 FileChannel 和 MappedByteBuffer 读取文件很可能会产生比任何涉及 FileInputStream 的解决方案都要快得多的解决方案。基本上，内存映射大文件，并为小文件使用直接缓冲区。
在 BufferedInputStream 的源代码中你会发现： private static int DEFAULT_BUFFER_SIZE = 8192;因此，您可以使用该默认值。但如果你能找出更多的信息，你就会得到更有价值的答案。例如，您的 adsl 可能会提供 1454 字节的缓冲区，这是因为 TCP/IP 的有效负载。对于磁盘，您可以使用与磁盘块大小匹配的值。
正如其他答案中已经提到的，使用 BufferedInputStreams。
在那之后，我猜缓冲区大小并不重要。要么程序受 I/O 限制，而且缓冲区大小超过 BIS 默认值，不会对性能产生任何重大影响。
或者程序在 MessageDigest.update() 中受 CPU 限制，并且大部分时间没有花费在应用程序代码中，因此对其进行调整将无济于事。
（嗯......有多个核心，线程可能会有所帮助。）
1024 适用于各种情况，尽管在实践中您可能会看到更大或更小的缓冲区大小会获得更好的性能。
这将取决于许多因素，包括文件系统块大小和 CPU 硬件。
为缓冲区大小选择 2 的幂也很常见，因为大多数底层硬件的结构都是 2 的幂的文件块和缓存大小。 Buffered 类允许您在构造函数中指定缓冲区大小。如果没有提供，它们使用默认值，在大多数 JVM 中是 2 的幂。
无论您选择哪种缓冲区大小，您将看到的最大性能提升是从非缓冲文件访问转变为缓冲文件访问。调整缓冲区大小可能会略微提高性能，但除非您使用非常小或非常大的缓冲区大小，否则不太可能产生显着影响。
