I/O Streams

Streams hold operating-system resources like file handles or sockets. If you never close them, those resources leak and can run out, and buffered data may never be written. Always close them when you are done.

BufferedInputStream wraps another stream and reads a big chunk of bytes at once into an in-memory array. Your reads come from that array instead of hitting the disk or network each time, so there are far fewer slow system calls.

They connect the byte world to the character world. InputStreamReader wraps a byte InputStream and decodes its bytes into characters using a charset. OutputStreamWriter wraps a byte OutputStream and encodes characters into bytes. They are the bridge between the two hierarchies.

Bytes are not text until you choose a character encoding (a charset) to interpret them. If you don't specify one, older Java uses the machine's default, so the same code produces different or corrupted text on different machines. Always pass an explicit charset, normally UTF-8.

flush() pushes data that is sitting in an in-memory buffer out to the underlying destination (file, socket, OS). You need it when you want buffered bytes to appear before you close the stream, such as on a long-lived socket.

ObjectOutputStream.writeObject turns an object (and everything it references) into bytes; ObjectInputStream.readObject rebuilds it. The class must implement the Serializable marker interface, and every field that should be saved must itself be serializable.

They are filter streams that read and write Java primitive types (int, double, boolean, etc.) and strings as raw bytes. You use them so you don't have to manually convert each primitive to and from bytes yourself.

Use Data streams for a small, fixed set of primitives and strings where you control the exact byte layout. Use Object streams when you need to save whole objects and their references automatically. Both are filter streams built on byte streams.

Each stream class wraps another stream of the same type and adds one behavior (buffering, data conversion, etc.). Because the wrapper has the same interface as what it wraps, you can stack wrappers in any order to combine features without subclassing every combination.

In UTF-8 some characters take more than one byte. If you treat each byte as a character, those multi-byte characters get split into several wrong characters, so accented and non-Latin text comes out garbled.

You can declare several resources in one try-with-resources; Java closes them automatically in reverse order. If the body throws and a close() also throws, Java keeps the body's exception as the main one and attaches the close() exception as a 'suppressed' exception so neither is lost.

Serialization remembers each object it has already written, so an object referenced from two places is saved once and cycles don't loop forever. Fields marked transient are not saved and come back as defaults.

Yes. Each layer sees the bytes the layer below produces, so wrapping order decides whether you buffer raw or compressed data. Put the buffer next to the slow source (the file/socket) so it batches real I/O, and remember to flush the whole chain before relying on the output.

Deserializing untrusted bytes can let an attacker run code on your machine, and changing a class can break old saved data. Avoid deserializing untrusted input, use input filters, and prefer schema-based formats like JSON or Protocol Buffers.

java.io streams are built with the decorator pattern: you wrap a base stream with layers that each add a feature, like buffering or character decoding. NIO is a newer, channel-and-buffer based API you reach for when you need better performance, non-blocking I/O, or fine-grained charset control.

Writing data passes through layers: your JVM buffer, then the operating system's cache, then the physical disk. flush() moves data from the JVM to the OS, close() flushes and releases the handle, but only an OS sync (fsync) forces the OS to write to the disk so it survives a power loss.

The java.io decorator streams (with BufferedInputStream/Reader) are simple, blocking, byte/character-at-a-time APIs that are great for straightforward sequential file and text work. NIO channels with ByteBuffers are lower-level and support non-blocking, selectable, and bulk transfers, which scale better for many concurrent connections.