What is a Selector in Java NIO and how does it let one thread serve many channels?

## The goal: many connections, few threads A naive server gives every connection its own thread that blocks on `read()`. With thousands of connections this wastes memory and scheduler time. A **Selector** solves this by letting **one thread watch many channels** and only do work for the ones that are actually ready. This is called **multiplexing** (combining many streams into one point of control). ## The cast of characters - **Channel** — an open connection (e.g. `SocketChannel`). Must be in **non-blocking** mode (`configureBlocking(false)`) to register with a selector. - **Selector** — created with `Selector.open()`. It holds a set of registrations and can wait for any of them to become ready. - **SelectionKey** — the token returned when you register a channel with a selector. It is the link between one channel and one selector and carries: the **interest set** (what you want to be told about) and the **ready set** (what's actually ready right now). It can also hold an `attachment()` — any object you stash for context (often a per-connection buffer/state). ## Registration and interest ops You register like this: ```java channel.register(selector, SelectionKey.OP_READ); ``` The last argument is the **interest set**, a bitmask of the operations you care about: - `OP_ACCEPT` — a `ServerSocketChannel` has an incoming connection to accept. - `OP_CONNECT` — a client `SocketChannel`'s connect handshake has finished. - `OP_READ` — there are bytes available to read. - `OP_WRITE` — the channel can accept bytes to write (its send buffer has room). You can combine them with bitwise OR, e.g. `OP_READ | OP_WRITE`. ## The selection loop The heart of a selector-based server is an **event loop**: ```java while (true) { selector.select(); // blocks until something is ready Iterator<SelectionKey> it = selector.selectedKeys().iterator(); while (it.hasNext()) { SelectionKey key = it.next(); it.remove(); // MUST remove — see below if (key.isAcceptable()) { /* accept new connection */ } else if (key.isReadable()) { /* read bytes */ } else if (key.isWritable()) { /* write bytes */ } } } ``` ### What `select()` does `select()` **blocks** the thread until at least one registered channel is ready for one of its interest ops, then returns the *number* of ready channels. Variants: `select(timeout)` returns after a timeout even if nothing is ready; `selectNow()` never blocks (returns 0 if nothing's ready); `wakeup()` (called from another thread) forces a blocked `select()` to return immediately. ### The two key sets - `selector.keys()` — **all** registered keys. - `selector.selectedKeys()` — the subset that became **ready** in the last `select()`. ### Why you must remove each selected key The selector **adds** ready keys to the selected set but **never removes** them. If you don't call `it.remove()` after handling a key, that key stays in the set and you'll "handle" it again on the next loop even though it may no longer be ready — a classic NIO bug causing busy spinning or processing stale events. ## Why this scales: OS readiness primitives A Selector doesn't poll each channel itself. It delegates to the operating system's efficient readiness notification facility — **epoll** on Linux, **kqueue** on macOS/BSD, and an IOCP/poll mechanism on Windows. These let the kernel wake the thread only when something happens, so waiting on 10,000 channels costs roughly the same as waiting on a few. This is what makes the **single-thread-many-channels** model viable. ## Where it fits This design — one thread (the *event loop* / *reactor*) demultiplexing events and dispatching handlers — is the **Reactor pattern**, the foundation of high-throughput servers such as **Netty**, **Vert.x**, and Node's libuv. Real systems usually run a small pool of such loops (one per CPU core) rather than literally one thread.