Java BufferedOutputStream strategy

Question

You can give the BufferedOutputStream constructor a int parameter for the buffer size. I my szenario I have one process writing to the disk and on process reading from the disk. Having a default buffer of 8192 bytes causes high fragmentation of big files.

Now I was wondering if I could reduce the fragmentation if I lift the buffer size to 1 Mb.

I think this should work. But does the BufferedOutputStream still respect my buffer if I always call BufferedOutputStream.write(smallBuffer,0,i); // i being smaller than 8192 BufferedOutputStream.write(smallBuffer,0,i); // i being smaller than 8192

i is small because I am catching small paketes (8192 bytes) over the net. But I want BufferedOutputStream to really buffer a lot, and not decide to flush earlier?

Is BufferedOutputStream "stupid" enough to wait until the buffer is full or flush() is called. Or has it got some time based flushing mechanism installed?

Answer 1

The BufferedOutputStream does not use any time based algorithm or other statistics to invoke flush internally. It will flush as soon as the buffer is full or you flush it explitily (or before the buffered stream is closed).

In other words: a larger buffer size will reduce fragmentation for your use case.

Answer 2

According to Javadoc :

Ordinarily this method stores bytes from the given array into this stream's buffer , flushing the buffer to the underlying output stream as needed.

http://download.oracle.com/javase/6/docs/api/java/io/BufferedOutputStream.html

And if you look at the sources (Sun implementation):

public synchronized void write(byte b[], int off, int len) throws IOException {
    //flushBuffer() if necessary
    System.arraycopy(b, off, buf, count, len);
    count += len;
}

The flushBuffer() occurs only if the data chunk is bigger than the whole buffer or if appending it to the buffer would cause overflow.

So to answer quickly: yes. And there is no implicit flush() , you have to call manually if necessary and buffer is not filled yet.