Netty source code simple analysis 1

Netty source code simple analysis 1

I briefly read the source code of netty5 over the weekend. I only understood the rough idea and recorded the results so that I can recall it next time.

Server code:

public void run() throws Exception {        EventLoopGroup bossGroup = new NioEventLoopGroup();        EventLoopGroup workerGroup = new NioEventLoopGroup();        try {            ServerBootstrap b = new ServerBootstrap();            b.group(bossGroup, workerGroup)             .channel(NioServerSocketChannel.class)             .childHandler(new ChannelInitializer
 
  () {                @Override                public void initChannel(SocketChannel ch) throws Exception {                    ch.pipeline().addLast(                            new ObjectEncoder(),                            new ObjectDecoder(ClassResolvers.cacheDisabled(null)),                            new ObjectEchoServerHandler(),                            new MyServerHandler());                }             });            // Bind and start to accept incoming connections.            b.bind(port).sync().channel().closeFuture().sync();                    } finally {            bossGroup.shutdownGracefully();            workerGroup.shutdownGracefully();        }    }
 

The EventLoopGroup class has four related classes that are easy to confuse:

EventExecutor EventExecutorGroup, EventLoop, EventLoopGroup,

EventExecutor inherits from EventExecutorGroup and EventExecutorGroup inherits from Executor (the class of thread pool service provided by java). EventExecutor is a special EventExecutorGroup that provides methods to detect whether a thread is executed in eventLoop.

EventLoopGroup also inherits from EventExecutorGroup and provides the EventLoop generation method next (),

EventLoop is inherited from EventLoopGroup. the English description of EventLoop is: Will handle all the I/O-Operations for a Channel once it was registered, which processes the channel io Operations,

The first bossGroup in the code is used to receive messages generated by the channel (similar to events that interest the channel through selector in NIo). Only one thread is executing this operation,

The second workerGroup is mainly used to process IO operations, and multiple threads are executing operations.

The ServerBootstrap class is mainly used to create the NioServerSocketChannel class and initialize it. It mainly depends on its bind () method, as shown below:

private ChannelFuture doBind(final SocketAddress localAddress) {        final ChannelFuture regFuture = initAndRegister();        final Channel channel = regFuture.channel();        if (regFuture.cause() != null) {            return regFuture;        }        final ChannelPromise promise;        if (regFuture.isDone()) {            promise = channel.newPromise();            doBind0(regFuture, channel, localAddress, promise);        } else {            // Registration future is almost always fulfilled already, but just in case it's not.            promise = new DefaultChannelPromise(channel, GlobalEventExecutor.INSTANCE);            regFuture.addListener(new ChannelFutureListener() {                @Override                public void operationComplete(ChannelFuture future) throws Exception {                    doBind0(regFuture, channel, localAddress, promise);                }            });        }        return promise;    }

The above code mainly involves two processes: one is to register the production channel, and the other is to bind the channel to the specified port,

The creation and registration methods are as follows:

final ChannelFuture initAndRegister() {        Channel channel;        try {            channel = createChannel();        } catch (Throwable t) {            return VoidChannel.INSTANCE.newFailedFuture(t);        }        try {            init(channel);        } catch (Throwable t) {            channel.unsafe().closeForcibly();            return channel.newFailedFuture(t);        }        ChannelPromise regFuture = channel.newPromise();        channel.unsafe().register(regFuture);        if (regFuture.cause() != null) {            if (channel.isRegistered()) {                channel.close();            } else {                channel.unsafe().closeForcibly();            }        }        // If we are here and the promise is not failed, it's one of the following cases:        // 1) If we attempted registration from the event loop, the registration has been completed at this point.        //    i.e. It's safe to attempt bind() or connect() now beause the channel has been registered.        // 2) If we attempted registration from the other thread, the registration request has been successfully        //    added to the event loop's task queue for later execution.        //    i.e. It's safe to attempt bind() or connect() now:        //         because bind() or connect() will be executed *after* the scheduled registration task is executed        //         because register(), bind(), and connect() are all bound to the same thread.        return regFuture;    }

The Code marked as red above indicates that the registration operation is actually completed by the unsafe tool class. It is mainly registered with the ServerSocketChannel class, which is similar to java NIO registration. The source code is as follows:

 protected void doRegister() throws Exception {        boolean selected = false;        for (;;) {            try {                selectionKey = javaChannel().register(eventLoop().selector, 0, this);                return;            } catch (CancelledKeyException e) {                if (!selected) {                    // Force the Selector to select now as the "canceled" SelectionKey may still be                    // cached and not removed because no Select.select(..) operation was called yet.                    eventLoop().selectNow();                    selected = true;                } else {                    // We forced a select operation on the selector before but the SelectionKey is still cached                    // for whatever reason. JDK bug ?                    throw e;                }            }        }    }

The channel class differs from the unsafe class: the channel class is mainly used for read and write operations by netty-based programmers, but the IO operations between netty AND NIo are mainly implemented through the unsafe class.

By analyzing the class inheritance relationship of the channel, we can find that some of the channel abstract classes also contain the implementation of the corresponding unsafe class, which is the inheritance structure of the NioServerSocketChannel class.

The AbstractNioMessageChannel and AbstractChannel classes both have the unsafe internal class as the actual operation IO class.