flush() in Java I/O
Fast recall
Quick revision
Core answer
flush() asks an output stream or writer to push buffered data to its intended downstream destination without closing it. Call it when the resource must stay open but a peer or protocol needs the data now; close normally flushes, and flush alone does not guarantee physical-disk durability.
Interview-ready guide
Interview answer
flush() sends buffered bytes or characters to the next destination while keeping the stream or writer open. In a chain of writers and output streams, flushing the outer writer also passes its pending output through the lower layers. It is used when the receiver must see the data now but the connection or file is not ready to close.
For example, a client writes PING and a line ending through a BufferedWriter, then waits for a reply. It must call flush() after the complete message. Otherwise PING may remain in memory: the client waits for the reply while the server waits for a request it has not received. Console prompts and long-lived request-response connections have the same kind of visibility boundary.
A final manual flush is usually unnecessary when try-with-resources closes the writer immediately, because closing a standard writer flushes its pending data first. Flushing after every character or every line can make output visible sooner, but it removes much of the performance benefit of buffering. The correct point to flush comes from the file or protocol requirement.
Flushing a file stream does not guarantee that the data has reached physical storage. It only passes Java's buffered data to the lower layer or operating system. Durable storage needs the appropriate file-channel or transaction guarantee. Use flush() for an intermediate visibility boundary, use close() when ownership ends, and handle errors from either operation.
flush() in Java I/O
Direct Answer
flush() asks an output stream or writer to push buffered data to its intended downstream destination without closing it. Call it when the resource must stay open but a peer or protocol needs the data now; close normally flushes, and flush alone does not guarantee physical-disk durability.
Deep Dive & Architecture
Application visibility means data has left Java's buffering layers far enough for the next participant to receive it. Logical completion means the producer has finished the message or resource and can close it. Physical durability asks whether storage will survive a crash. One method cannot promise all three.
A protocol should define its own message boundary—newline, length, frame, or close—and flush when the receiver needs that complete unit. Too-late flushing can deadlock a request/response exchange; too-early flushing creates many small writes.
Some classes have special auto-flush behavior. A PrintWriter configured for auto-flush does so only for particular methods such as println, printf, or format, not after every call to write or print.
Code Example
import java.io.BufferedWriter;
import java.io.StringWriter;
class FlushBoundary {
public static void main(String[] args) throws Exception {
var destination = new StringWriter();
try (var writer = new BufferedWriter(destination)) {
writer.write("PING");
writer.newLine();
writer.flush(); // message boundary; writer remains open
System.out.print(destination.toString());
}
}
}
Check your understanding
Answer these without looking back at the article.
- Does flush close the stream?
- Why can missing flush deadlock a request-response protocol?
- Does OutputStream.flush guarantee physical disk durability?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.