Event cycle group

 

All I / O operations in Netty are asynchronous, and the asynchronous execution results are obtained by channelfuture.

Asynchronously executes a thread pool EventLoopGroup, it inherits ExecutorService.

This place is a group, store a bunch of EventLoop, and EventLoop inherits EventExecutor, so EventLoopGroup's execute () method can constantly call next () to lose the next thread, is a thread pool, full asynchronous.

BoosGroup&WorkGroup

The I / O event of the Web system is not read / write / connection / accept.

Based on the React model, Netty can set two EventLoopGroup, where EventLoop (thread) can be adjusted as needed. Boosgroup and Workgroup division differently.

Boosgroup is used to monitor and process the Accept events that the client connection, and Workgroup is responsible for the Read / Write event handling.

 

In the NETTY architecture, in the forefront responsible for the XXX client connection is Acceptor, when the Server end is developed, there is only one serverbootstrapacceptor, which is the internal class of ServerBootstrap, inherits the ChannelHandleRadapter object, that is, ChannelHandler.

The startup process of ServerBootStrap is - in the init () method underlay, the dobind0 method is called, which triggers the EventLoopGroup.execute () method, after the EVENTLOOP thread performs the NIO SELECT, and triggered the processSelectedKey () method, when listened to the Read / Accept event If you trigger the ChannelRead () method of each ChannelHandler in PIPELINE, you will trigger the ChannelHandleradapter's ChannelRead ().

 

Acceptor's functionality, the ChannelRead () method of CHANNELHANDLERADAPTER is implemented - this gathering is to connect the received client (NiosocketChannel), and register from one of the EventLoop associated by WorkGroup to the SelectLoop-associated Selector (multiplexer), follow-up When the connection is read, it will be processed by the same NiOEventLoop - SELECT and throws the child pipeline.

 

CHANELPIPELINE principle

The ChannelPipeline data structure is a two-way linked list, with two attributes, TAIL points to the chain head and chain end, respectively;

Each element of ChannelPipeline is a ChannelHandlerContext, where NEXT and PREV points to the front and rear elements, respectively;

Hold a reference to a ChannelHandler in each ChannelHandlerContext, and they are responsible for specific I / O event processing.

Typical responsibility chain mode, CHANNELPIPELINE.FIRECHANELREAD () will trigger the Head node to start read (), in the handler, by calling context.fireChannelRead () to schedule the next node in the liability chain to perform read ().

If not called, the current handler is finished.

Similar to Javax.Filter.

 

The scheduling of the execution link is single-thread, but Connect, Write and other methods are asynchronous, calling Workgroup.execute () and returns a ChannelFuture object.

After Netty's NiOEventLoop reads the message, call ChannelPipeline directly.fireChannelRead (Object msg). As long as the user does not active switching thread, it has always been called the user's ChannelHandler, during which the thread switching is not performed. This series of serialization avoids the competition of the lock caused by multi-threaded operations, which is optimal from the perspective of performance.

Read / write incident processing

The read event is basically consistent with the Accept event. It is the Workgroup EventLoop executes the Selector I / O event polling. If there is an event, you call UNSAFE to complete the read data, and throw the read data to each Channel corresponding to the Pipeline.

About writing events, you can call the Write method to write data through the ChannelHandlerContext, which is full.

When SELECT in Workgroup is ready, Channel.unsafe (). ForceFlush (), the underlying final call DowrteMessage () writes the data, the standard NIO gameplay is written by Javachannel.

 

Play

(1) Time controllable simple business directly on I / O thread

Time controllable simple business is processed directly on the I / O thread. If the business is very simple, the execution time is very short, there is no need to interact with external networks, access the database, and disk, no need to wait for other resources, it is recommended to be directly in the business channeller. Execution, threads or thread pools that do not need to be restarted. Avoid thread context switching, no thread concurrent problems.

(2) Complex and time uncontrollable business recommendations are delivered to the backend business thread pool unified processing

The complexity is high or the time uncontrollable service is recommended to deliver the rear service thread pool unified processing. For such business, it is not recommended to start the thread or thread pool processing directly in the business channeller. It is recommended to unify different services into task, unified Delivery to the business thread pool of the backend. Excessive business ChannelHandler will bring development efficiency and maintainability issues, do not use Netty as a business container, for most complex business products, still need to integrate or develop their own business containers, do well and Netty architectural layers .

(3) Business thread avoid direct operation of CHANNELHANDALER

Business thread avoid direct operation of ChannelHandler, can be operated for ChannelHandler, IO threads, and business threads because services are usually multi-threaded models, so there is a multi-threaded operation CHANNELHANDLER. In order to avoid multithreading complicated issues, it is recommended to follow the Netty itself by NiOEventLoop by NiOEventLoop by NiOEventLoop by NiOEventLoop, instead of business threads.