NIO & NIO.2

All three make a new buffer that shares the same underlying data as the original (a window onto it) but has its own independent position, limit, and mark. duplicate() mirrors the whole buffer, slice() exposes only the part from position to limit, and asReadOnlyBuffer() makes a view you can read but not write.

Loop: clear() the buffer, read() from the source into it, if read returns -1 stop, flip() it, then write() to the destination in a loop until no bytes remain. Because a single write() may not drain the whole buffer, you loop on hasRemaining(); flip and clear switch the buffer between filling and draining each iteration.

Scatter/gather lets a channel read into several buffers in one call (scatter) or write from several buffers in one call (gather). It's useful when a message has fixed parts, like a header and a body — you can read straight into separate buffers, or build a message from separate header and body buffers and write it all at once.

transferTo and transferFrom move bytes directly from one channel to another without you allocating a ByteBuffer and looping read/write yourself. They are called zero-copy because the operating system can move the data inside the kernel without copying it into your Java program's memory, which makes things like serving a file over a socket much faster.

When you write through a memory-mapped file, the changes sit in memory and the OS decides when to save them to disk. force() tells the OS to flush those changes to disk now, so they aren't lost if the program or machine crashes.

Mapped files can't be reliably unmapped before the buffer is garbage-collected, so files may stay locked (notably on Windows). One mapping can't exceed about 2 GB. And writes aren't safe on disk until you call force(). Plan for all three.

Files.readAllLines reads the whole file into a List in memory at once. Files.lines returns a lazy Stream that reads line-by-line, so it handles huge files, but you must close the stream (use try-with-resources) because it holds an open file handle.

Files.walk returns a lazy Stream of all paths under a directory, great for simple filtering — but you must close it. Files.walkFileTree uses a visitor callback giving fine control over each file, directory entry/exit, and errors, which is better for complex traversals like recursive delete.

Main pitfalls: forgetting to remove handled keys from selectedKeys() (causes reprocessing), leaving OP_WRITE always on (busy spin), ignoring partial reads/writes, blocking inside the loop, and not handling -1 from read() (peer closed). Fix each by following the correct NIO idioms.

The Reactor pattern uses one (or a few) event-loop threads that wait for I/O readiness and dispatch each ready event to a handler. Java's Selector is exactly this: select() detects readiness, and you route OP_READ/OP_WRITE/OP_ACCEPT to the right code. It lets a server handle many connections with few threads.

OVERFLOW means the watch service dropped some change events because they arrived faster than your program consumed them. When you see it, you can't trust your event list is complete, so you should re-scan the directory to find out the real current state.

WatchService doesn't watch subfolders automatically. To watch a whole tree, you walk the directory tree once and register every directory, keep a map from each WatchKey to its directory, and whenever a new subdirectory is created (an ENTRY_CREATE you observe) you register that one too.

Open an AsynchronousServerSocketChannel, bind a port, and call accept with a handler. When a client connects, the handler gets the new connection, immediately calls accept again for the next client, and starts reading. Each read's handler writes the data back, then reads again.

asReadOnlyBuffer() returns a buffer that shares the same data but rejects any write (put throws). You use it to safely hand out a buffer's contents so callers can read but not modify the underlying bytes.

Use the Files helpers like size(), isDirectory(), getLastModifiedTime(), or read a whole bundle with Files.readAttributes(path, BasicFileAttributes.class). For OS-specific data like Unix permissions you request a PosixFileAttributes view. One bulk read is cheaper than many separate calls.

WatchService is great for low-to-moderate change rates because it's efficient and event-driven. For very high throughput or strict reliability, you usually pair it with periodic reconciliation (or replace it), because it can drop events (OVERFLOW), behaves differently per OS, and isn't recursive. The robust design is event-driven for speed plus a safety net that re-scans.