这更像是良心问题，而不是技术问题：p 我正在编写一些 java 代码来从服务器下载文件...为此，我使用的是 BufferedOutputStream 方法 write() 和 BufferedInputStream 方法 read()。
所以我的问题是，如果我使用缓冲区来保存字节，那么要读取的字节数应该是多少？当然，我可以使用 int byte = read() 然后 write(byte) 逐字节读取，或者我可以使用缓冲区。如果我采用第二种方法，在定义每次读取\写入的字节数时，是否有哪些方面我必须注意？这个数字会对我的程序产生什么影响？
感谢
【问题讨论】：
标签： java download bufferedinputstream bufferedoutputstream
您的网络连接中的 MTU（最大流量单位）是多少？例如，如果您使用 UDP，则可以检查此值并使用较小的字节数组。如果这是没有办法的，你需要检查内存是如何吃掉你的程序的。我认为1024 - 4096 将是保存这些数据并继续接收的好变体
【讨论】：
除非您的网络连接速度非常快，否则缓冲区的大小几乎没有什么区别。我会说 4k 缓冲区就可以了，尽管使用更大一点的缓冲区也没有什么坏处。
这可能同样适用于使用read() 与read(byte[]) ...假设您使用的是BufferedInputStream。
除非您有一个非常快速/低延迟的网络连接，否则瓶颈将是网络和您的计算机网络接口可以维持的数据速率。对于典型的 Internet 连接，应用程序移动数据的速度可以比网络快两个或更多数量级。因此，除非您做一些愚蠢的事情（例如在无缓冲的流上读取 1 个字节），否则您的 Java 代码不会成为瓶颈。
【讨论】：
BufferedInputStream 和 BufferedOutputStream 通常依赖 System.arraycopy 来实现。 System.arraycopy 有一个本地实现，它可能依赖于 memmove 或 bcopy。复制的内存量将取决于缓冲区中的可用空间，但无论如何，到本机代码的实现非常有效，无论您正在读取/写入多少字节，都不太可能影响应用程序的性能。
但是，对于 BufferedInputStream，如果您设置了一个具有上限的标记，则可能需要创建一个新的内部缓冲区。如果确实使用了标记，则读取的字节数超过旧缓冲区中的可用字节数可能会导致暂时的性能下降，尽管摊销后的性能仍然是线性的。
正如 Stephen C 所提到的，由于网络，您更有可能看到性能问题。
【讨论】：
如果您抽取数据，通常不需要使用任何缓冲流。只需确保您使用传递给 read 方法的适当大小（8-64k）的临时 byte[] 缓冲区（或使用执行此操作的泵方法）。对于大多数用途，默认缓冲区大小太小（如果您使用更大的临时数组，无论如何它都会被忽略）
【讨论】：