在性能方面，在什么时候用BufferedOutputStream包裹FileOutputStream才有意义？

Question

我有一个模块，负责读取，处理和将字节写入磁盘。字节通过UDP传入，并且在组装完各个数据报之后，要处理并写入磁盘的最终字节数组通常在200字节至500,000字节之间。有时，组装后会有字节数组超过500,000个字节，但是这些数组相对较少。

我目前正在使用FileOutputStream的write(byte\[\])方法。我还尝试将包裹在FileOutputStream中BufferedOutputStream，包括使用接受缓冲区大小作为参数的构造函数。

看来，使用BufferedOutputStream会趋向于稍微提高性能，但是我才刚刚开始尝试使用不同的缓冲区大小。我只有一组有限的示例数据可以使用（示例运行中的两个数据集，可以通过应用程序进行传递）。给定我知道的数据信息，我是否可以运用一般的经验法则来尝试计算最佳缓冲区大小，以减少磁盘写操作并最大程度地提高磁盘写性能？

Answer 1

当写入小于缓冲区大小（例如8
KB）时，BufferedOutputStream会提供帮助。对于较大的写入，它无济于事，也不会使其变得更糟。如果您的所有写操作都大于缓冲区大小，或者每次写操作后始终都使用flush（），则我不会使用缓冲区。但是，如果您的写入中有很大一部分小于缓冲区大小，并且您并非每次都使用flush（），那么值得这样做。

您可能会发现将缓冲区大小增加到32 KB或更大可以对您有所改善，或者使情况变得更糟。青年汽车

您可能会发现BufferedOutputStream.write的代码很有用

/**
 * Writes <code>len</code> bytes from the specified byte array
 * starting at offset <code>off</code> to this buffered output stream.
 *
 * <p> Ordinarily this method stores bytes from the given array into this
 * stream's buffer, flushing the buffer to the underlying output stream as
 * needed.  If the requested length is at least as large as this stream's
 * buffer, however, then this method will flush the buffer and write the
 * bytes directly to the underlying output stream.  Thus redundant
 * <code>BufferedOutputStream</code>s will not copy data unnecessarily.
 *
 * @param      b     the data.
 * @param      off   the start offset in the data.
 * @param      len   the number of bytes to write.
 * @exception  IOException  if an I/O error occurs.
 */
public synchronized void write(byte b[], int off, int len) throws IOException {
    if (len >= buf.length) {
        /* If the request length exceeds the size of the output buffer,
           flush the output buffer and then write the data directly.
           In this way buffered streams will cascade harmlessly. */
        flushBuffer();
        out.write(b, off, len);
        return;
    }
    if (len > buf.length - count) {
        flushBuffer();
    }
    System.arraycopy(b, off, buf, count, len);
    count += len;
}