I/O & NIO

// Byte stream: for binary data
try (InputStream in = new FileInputStream("image.png")) {
    byte[] buffer = new byte[1024];
    int bytesRead = in.read(buffer);
}

// Character stream: for text data, handles encoding automatically
try (Reader reader = new InputStreamReader(new FileInputStream("text.txt"), StandardCharsets.UTF_8)) {
    int character = reader.read();  // reads a decoded Unicode character, not a raw byte
}

Common follow-ups: What happens if you read multi-byte UTF-8 encoded text using a raw byte stream without proper decoding?;Why does the JDK provide both a byte-stream and character-stream class hierarchy instead of just one unified approach?

// Unbuffered: potentially one system call PER character read
Reader unbuffered = new FileReader("large.txt");
int c;
while ((c = unbuffered.read()) != -1) { /* process character */ }  // slow for large files

// Buffered: reads in large chunks internally, dramatically fewer system calls
BufferedReader buffered = new BufferedReader(new FileReader("large.txt"));
String line;
while ((line = buffered.readLine()) != null) { /* process line */ }  // much faster

Common follow-ups: What's a reasonable default buffer size, and does it matter much for typical use cases?;Does BufferedReader's readLine() handle different line-ending conventions (\n vs \r\n) correctly across platforms?

// Non-blocking channel-based I/O with a Selector managing multiple connections on ONE thread
Selector selector = Selector.open();
SocketChannel channel = SocketChannel.open();
channel.configureBlocking(false);
channel.register(selector, SelectionKey.OP_READ);

while (true) {
    selector.select();  // blocks only until AT LEAST ONE registered channel is ready
    for (SelectionKey key : selector.selectedKeys()) {
        if (key.isReadable()) { /* handle the ready channel without blocking */ }
    }
}

Common follow-ups: How does a Selector's select() call efficiently determine which of potentially thousands of registered channels are actually ready, without polling each one individually?;How do virtual threads (Project Loom) change the calculus of choosing between blocking java.io and non-blocking java.nio for high-concurrency scenarios?

Path path = Path.of("data", "config.txt");

// Comprehensive, well-designed utility methods with informative exceptions
List<String> lines = Files.readAllLines(path, StandardCharsets.UTF_8);
Files.copy(path, Path.of("backup", "config.txt"), StandardCopyOption.REPLACE_EXISTING);

// Recursive directory walk, returning a lazily-evaluated Stream
try (Stream<Path> walk = Files.walk(Path.of("."))) {
    walk.filter(Files::isRegularFile).forEach(System.out::println);
}

Common follow-ups: Why does Files.delete() throw a specific exception on failure while File.delete() just silently returns false?;How does Path's relationship to the java.nio.file.FileSystem abstraction enable working with non-default file systems (like a ZIP file treated as a file system)?

try (FileChannel channel = FileChannel.open(Path.of("large_data.bin"), StandardOpenOption.READ)) {
    MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_ONLY, 0, channel.size());
    // Access file content directly as memory -- OS pages content in/out transparently as accessed
    byte firstByte = buffer.get(0);
    byte middleByte = buffer.get(channel.size() / 2);  // random access, only that specific page gets loaded
}

Common follow-ups: What are the specific challenges around safely unmapping a MappedByteBuffer, historically a notorious pain point in Java?;When would traditional stream-based sequential reading actually outperform memory-mapped access for a given access pattern?

public class User implements Serializable {
    private static final long serialVersionUID = 1L;  // explicit, stable version identifier
    private String name;
    private transient String temporaryToken;  // 'transient' excludes this field from serialization entirely
}

try (ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("user.dat"))) {
    out.writeObject(new User());
}

Common follow-ups: What does the transient keyword do, and why would you want to exclude a field from serialization?;Why has Java's built-in serialization mechanism come to be viewed with security skepticism in modern practice, and what alternatives are commonly preferred?

// DANGEROUS: deserializing untrusted input directly
public Object deserializeUntrusted(byte[] untrustedData) throws Exception {
    try (ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(untrustedData))) {
        return in.readObject();  // could trigger a gadget-chain exploit if the byte data is maliciously crafted
    }
}

// SAFER: use a restrictive JSON library with explicit type allowlisting instead of native Java serialization
// for any data originating from outside the trust boundary

Common follow-ups: What is a 'gadget chain' specifically, and why does simply having certain libraries on the classpath create risk even if your own code never intentionally uses them for this purpose?;What mitigations exist if native Java serialization genuinely must be used (like ObjectInputFilter)?

try (FileInputStream fis = new FileInputStream("data.txt.gz");
     GZIPInputStream gzis = new GZIPInputStream(fis);
     BufferedReader reader = new BufferedReader(new InputStreamReader(gzis, StandardCharsets.UTF_8))) {
    String line;
    while ((line = reader.readLine()) != null) {
        System.out.println(line);
    }
}  // all three resources closed automatically, in reverse order: reader, then gzis, then fis

Common follow-ups: Is it actually necessary to declare all three resources explicitly, given closing just the outermost reader would typically cascade through to close the underlying wrapped streams as well?;What happens if one of the resources fails to construct successfully partway through the declaration list -- are the already-constructed ones still closed properly?

AsynchronousFileChannel channel = AsynchronousFileChannel.open(Path.of("data.bin"), StandardOpenOption.READ);
ByteBuffer buffer = ByteBuffer.allocate(1024);

channel.read(buffer, 0, buffer, new CompletionHandler<Integer, ByteBuffer>() {
    public void completed(Integer bytesRead, ByteBuffer attachment) {
        System.out.println("Read " + bytesRead + " bytes asynchronously");
    }
    public void failed(Throwable exc, ByteBuffer attachment) {
        System.err.println("Read failed: " + exc.getMessage());
    }
});
// Calling thread continues immediately, notified later via the CompletionHandler callback

Common follow-ups: How does AsynchronousFileChannel's read()/write() Future-based overload compare to its CompletionHandler-based overload in terms of typical usage patterns?;What's the underlying OS-level mechanism (like io_uring on Linux) that enables genuinely asynchronous file I/O beneath this API?

WatchService watcher = FileSystems.getDefault().newWatchService();
Path dir = Path.of("watched-folder");
dir.register(watcher, StandardWatchEventKinds.ENTRY_CREATE, StandardWatchEventKinds.ENTRY_MODIFY);

while (true) {
    WatchKey key = watcher.take();  // blocks until a change occurs
    for (WatchEvent<?> event : key.pollEvents()) {
        System.out.println(event.kind() + ": " + event.context());
    }
    key.reset();  // MUST call reset() to continue receiving further events for this key
}

Common follow-ups: Why is calling key.reset() after processing events critical, and what happens if it's forgotten?;What are WatchService's known platform-specific limitations or reliability caveats (like on certain network file systems)?