The center of this article

1. Traditional IO model (before NIO appeared, that is, BIO)
2. Reactor model (asynchronous, non-blocking, event-driven model)
3. Netty's implementation of Reactor model

1. Traditional IO model (before NIO appeared, that is, BIO)

Let's first look at the thread communication model of BIO

Explanation

1. Application (application side) initiates a request (user thread) to Kernel (computer core)
2. The data in the kernel processing is not ready yet.Waiting for datastatus
3. Until the Kernel data is processed, copy the data from the kernel to the user thread
4. After copying the data, return to Applicatoin to process the data

Off-topic: Throughout the process, the threads are synchronized from the user state to the kernel state to the user state, and the user thread has been waiting until the result returns

2. Reactor model (asynchronous, non-blocking, event-driven model)

The Reactor model (reactor mode) is divided into 3 categories: single-threaded, multi-threaded, master-slave multi-threaded

   1. Single-threaded Reactor model

Explanation

1. After multiple clients send requests to the server at the same time, register the notification event and return directly, without blocking and waiting (Selecter single-thread infinite loop scanning)
2. Server uses a thread to receive the request and assign Handler to process (each handler is a thread)
3. After the handler is processed, call the notification event registered in step 1 and return the result

Disadvantages:

Although we have realized that Client requests are not blocked and requests are processed asynchronously, you can see in the single figure that receiving requests and assigning handlers is still single-threaded processing, and there are still problems.

1. Single-thread wasting CPU resources

2. If there is a processing exception in the single-threaded part of the figure, there will be blocking, and there will be a bottleneck when the Client is too concurrent

So it attracts multiple threads

2. Multi-threaded Reactor model

Explanation

1. Compared with single-threaded, currently the only place to receive the request thread is in single-threaded
2. Thread pool technology is used for asynchronous processing of multi-threads when receiving thread allocation handler processing, and the handlers do not affect each other

defect:

We see that the acceptor thread is still in a single-threaded receiving state. If there is a large IO operation, it will inevitably affect other

Thus introducing master-slave multithreading

3. Master-slave multi-threaded Reactor model

Explanation:

Compared with multi-threading, Reactor is divided into mainReactor and subReactor by one

2. mainReactor: mainly used to receive client requests, pass the received SocketChannel to subReactor, and subReactor is responsible for communication with the client

3. Benefits: mainReactor is only responsible for receiving client requests and adapting subReactor and not responsible for real communication. Each subReactor thread has independent Selector, thread, event logic, and will not block other threads because of large IO

3. Netty's implementation of the Reactor model

    1. Mode correspondence:
Netty server uses "multi-reactor thread mode"
MainReactor ———— A NioEventLoop in bossGroup (NioEventLoopGroup)
SubReactor ———— A NioEventLoop in workerGroup (NioEventLoopGroup)
        acceptor ———— ServerBootstrapAcceptor
ThreadPool ———— User-defined thread pool

2. Netty startup process (extracted from the network, not verified yet, probably the process should be correct)

1. When the server program starts, ChannelPipeline will be configured. ChannelPipeline is a ChannelHandler chain. All events will trigger a method in Channelhandler. This event will be propagated in the ChannelHandler chain in ChannelPipeline. Then, get a NioEventLoop from the bossGroup event loop pool to display the server port binding operation of the server program, register the corresponding ServerSocketChannel to the Selector in the NioEventLoop, and register the ACCEPT event as the event of interest to the ServerSocketChannel.
2. The NioEventLoop event loop starts, at this time it starts to listen for client connection requests.
3. When a client initiates a connection request to the server, the event loop of NioEventLoop listens to the ACCEPT event. Netty bottom layer will receive this connection, get the connection (SocketChannel) with this client through the accept () method, and then trigger the ChannelRead event (ie , The channelRead method in ChannelHandler will get callback), this event will be executed and propagated in the ChannelHandler chain in ChannelPipeline.
4. The readChannel method of ServerBootstrapAcceptor registers the SocketChannel (client connection) to a Selector of a NioEventLoop in workerGroup (NioEventLoopGroup), and registers the READ event as an event of interest to SocketChannel. Start the event loop of the NioEventLoop where the SocketChannel is located, and then you can start the communication between the client and the server.