Memory-Mapped Files & File Locking

## The problem memory mapping solves Normally, to read a file you call something like `channel.read(buffer)`. The operating system copies bytes from the disk into the kernel's page cache, then copies them again from the kernel into your program's buffer. To write, the reverse happens. For large files or random access, all that copying and all those system calls are expensive. **Memory mapping** removes the explicit copy and the per-operation system call. Instead of *asking* the OS for bytes, you tell the OS: "make this file region appear in my address space as if it were ordinary memory." After that, reading byte 5,000,000 of the file is just reading memory location `base + 5,000,000`. No `read()` call. ## How it works under the hood Modern CPUs use **virtual memory**: programs see virtual addresses, and the OS maps each page (typically 4 KB) of virtual address space to a page of physical RAM (or to disk). Memory mapping reuses this machinery. When you map a file, the OS sets up page-table entries that point at the file. The pages start out **not loaded**. The first time your code touches a page, the CPU raises a *page fault*; the OS catches it, reads that page from the file into the page cache, fixes the page table, and resumes your code — transparently. This is **demand paging**: only the parts you actually touch are loaded. Dirty (modified) pages are written back to disk later by the OS, or immediately when you call `force()`. ## The Java API ```java try (FileChannel ch = FileChannel.open(path, StandardOpenOption.READ, StandardOpenOption.WRITE)) { MappedByteBuffer buf = ch.map(FileChannel.MapMode.READ_WRITE, 0, ch.size()); byte first = buf.get(0); // read like an array buf.put(0, (byte) 42); // write like an array } ``` `FileChannel.map(MapMode mode, long position, long size)` returns a `MappedByteBuffer` (a subclass of `ByteBuffer`). Terms: - **FileChannel** — Java's NIO object representing an open file you can read/write/map. You get one from `FileChannel.open(...)` or from a stream's `getChannel()`. - **MappedByteBuffer** — a `ByteBuffer` whose backing storage is the mapped file region rather than ordinary heap/native memory. - **position / size** — the byte offset in the file where the mapping starts and how many bytes it covers. ### The 2 GB limit `size` is a `long`, but a `ByteBuffer`'s capacity is an `int`. So one mapping can cover at most `Integer.MAX_VALUE` (~2.1 GB) bytes. Larger files require multiple mappings. (Java 21+ adds the Foreign Function & Memory API / `MemorySegment` to map larger regions without this cap.) ## When mapping helps — and when it doesn't Good fit: large files, random access, repeated access to the same regions, sharing data between processes. Poor fit: small files (mapping overhead isn't worth it), purely sequential one-pass reads (a buffered stream is often as fast and simpler), or when you need deterministic resource release (see below). ## The unmapping gotcha There is **no public, portable `unmap()`** in standard Java before the FFM API. A mapping is released when its `MappedByteBuffer` is garbage-collected. Until then the OS may keep the file open/locked — on Windows this can block deleting or renaming the file. This non-deterministic cleanup is the single most surprising part of the API, and a frequent interview point. ## Summary Memory mapping turns file I/O into memory access by leveraging virtual memory and demand paging, eliminating user-space copies and per-operation syscalls. You create it with `FileChannel.map(mode, position, size)` → `MappedByteBuffer`, mind the ~2 GB-per-mapping limit, call `force()` to flush writes durably, and remember cleanup is GC-bound.