Understanding Server Thread Models: Blocking I/O, Reactor, and Proactor

1. Thread Model 1: Traditional Blocking I/O Service Model

In the blocking I/O model, each connection requires an independent thread to perform input, business processing, and output. The model uses blocking I/O to read data, which leads to two main problems: high resource consumption when many threads are created for large concurrency, and thread waste when a thread blocks on a read operation with no data available.

2. Thread Model 2: Reactor Pattern

2.1 Basic Introduction

The Reactor pattern solves the two drawbacks of the blocking I/O model by combining I/O multiplexing with a thread‑pool. Multiple connections share a single blocking object; the OS notifies the application when data is ready, allowing the thread to resume processing. Thread‑pool reuse further reduces thread creation overhead.

The Reactor consists of two key components:

Reactor : runs in a single thread, listens for events, and dispatches them to appropriate handlers.

Handlers : execute the actual I/O operations in a non‑blocking manner.

There are three typical implementations based on the number of Reactors and worker threads:

2.2 Single Reactor Single Thread

The Reactor uses Select to monitor client requests. When a connection is established, an Acceptor creates a Handler to process the connection. The Handler performs the full read‑process‑send cycle. This model is simple but cannot fully utilize multi‑core CPUs and suffers from a single‑thread bottleneck.

2.3 Single Reactor Multi‑Thread

Here the Reactor still runs in one thread to accept events, but the actual business logic is delegated to a worker thread pool. The Handler only reads data and hands it off to workers, which then process the request and send the response back. This improves CPU utilization but introduces complexity in thread‑safe data sharing and can become a bottleneck under very high concurrency.

2.4 Master‑Slave Reactor Multi‑Thread

The Master Reactor (MainReactor) monitors new connection events and hands them to an Acceptor. Accepted connections are then assigned to SubReactors, each with its own Handler and worker pool. This separates connection acceptance from request processing, simplifying data exchange and improving scalability. It is widely used in servers like Nginx, Memcached, and Netty.

2.5 Summary

The three Reactor variants can be likened to a restaurant: a single‑thread model has one person handling both reception and service; the single‑reactor multi‑thread model has one receptionist and multiple waiters; the master‑slave model has multiple receptionists and waiters. Reactor offers fast response, simpler programming, good scalability, and high reusability.

3. Thread Model 3: Proactor Model

The Proactor model moves the actual I/O operation to the operating system using asynchronous I/O. An Initiator registers the operation with the kernel; once the OS completes the I/O, it notifies the Proactor, which then invokes the appropriate Handler for business processing. Compared to Reactor, Proactor can achieve higher efficiency by leveraging DMA, but it introduces greater programming complexity, higher memory usage for buffers, and limited OS support (e.g., full async I/O only on Windows IOCP or recent Linux kernels).