- 服务端发现新连接
- 循环读取read事件
- 将新连接交给pipeline处理
- 收尾工作
- 清除感兴趣事件
- 两种Channel的类比关系
- 感想
服务端发现新连接
在服务端启动过程中,ServerBootstrap通过反射的方式创建了一个NioServerSocketChannel,并且绑定了OP_ACCEPT感兴趣事件。启动之后,bossGroup中的NioEventLoop线程不断轮询这些事件,并进行处理。
前一节已经简述了一下processSelectedKey方法的代码,这里单独抽出处理OP_ACCEPT的相关代码
if ((readyOps & (SelectionKey.OP_READ | SelectionKey.OP_ACCEPT)) != 0 || readyOps == 0) {
unsafe.read();
}
netty将OP_ACCEPT和OP_READ统一视为read事件,所以这里两种事件一起判断。继续跟进unsafe.read,这里是NioMessageUnsafe对象
private final List
read代码比较长,可以分为如下几部分
- 检测是否为nioEventLoop线程
- 拿到config和pipeline
- 创建并初始化一个ByteBufAllocator.Handle,这个Handle可以动态变更缓冲区的容量。
- 循环读取read事件
- 将新连接交给pipeline处理
- 收尾工作
- 若不满足条件,移除感兴趣事件
循环读取read事件
前两个步骤无需多言,步骤3不是本章重点,略过。于是来到步骤4,先看一下doReadMessage方法
protected int doReadMessages(List buf) throws Exception {
SocketChannel ch = SocketUtils.accept(javaChannel());
if (ch != null) {
buf.add(new NioSocketChannel(this, ch));
return 1;
}
return 0;
}
在这个方法里,netty调用底层的ServerSocketChannel去接受一个新连接,并将它放入临时的readBuf容器内。出方法后,若接收到了新连接,allocateHandle记录一下连接数。循环的判断出口是一个比较复杂的逻辑关系,在接入新连接时,totalMessages为1,而maxMessagePerRead默认为16,所以这里返回false,也就不会继续循环。
// 继承于MaxMessageHandle的方法
public boolean continueReading() {
return continueReading(defaultMaybeMoreSupplier);
}
public boolean continueReading(UncheckedBooleanSupplier maybeMoreDataSupplier) {
return config.isAutoRead() && (!respectMaybeMoreData || maybeMoreDataSupplier.get()) &&
totalMessages < maxMessagePerRead && totalBytesRead > 0;
}
将新连接交给pipeline处理
对每一个readBuf容器内的新连接事件,都调用pipeline的fireChannelRead事件。pipeline首先会交给headContext,由headContext调用channelRead方法向下传递。在服务端启动过程中,ServerBootStrap将一个ServerBootstrapAcceptor设置在了pipeline中,先来回顾一下它。
// ServerBootstrap的init方法截取
pipeline.addLast(new ServerBootstrapAcceptor(ch, currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs));
ServerBootstrapAcceptor将ServerSocketChannel及用户设置的多个属性都添加了进来,并将自身添加到pipeline中。也因此,head传播read事件时,会调用ServerBootstrapAcceptor的channelRead方法,channelRead方法将客户端相关的childHandler、childOptions、childAttributes都设置到NioSocketChannel上,除了handler外,都是使用netty时用户自定义的部分。而handler是一个HandlerInitializer,在完成它的initChannel方法后,会将自身从pipeline删除,而用户在initChannel方法中添加的handler则会保留,从而在新连接接入时服务。
public void channelRead(ChannelHandlerContext ctx, Object msg) {
final Channel child = (Channel) msg;
child.pipeline().addLast(childHandler);
setChannelOptions(child, childOptions, logger);
setAttributes(child, childAttrs);
childGroup.register(child).addListener(new ChannelFutureListener() {
@Override
public void operationComplete(ChannelFuture future) throws Exception {
if (!future.isSuccess()) {
forceClose(child, future.cause());
}
}
});
}
在添加完成后,从workerGroup中挑选一个NioEventLoop,将NioSocketChannel注册到上面。这部分代码与服务端几乎相同。
时序图如下
与服务端稍有不同的是unsafe的register0方法中。在服务端启动时,因为还只是注册而没有绑定端口,isActive为false,从而不会启动,而到了bind完成后,服务端才会调用pipeline.fireChannelActive,从而开始各自的读事件。
if (isActive()) {
if (firstRegistration) {
pipeline.fireChannelActive();
} else if (config().isAutoRead()) {
beginRead();
}
}
收尾工作
从代码上可以看出收尾工作一共3步
- 清空readBuf容器
- 调用Allocator.Handle的readComplete方法
- 调用pipeline.fireChannelReadComplete方法
步骤1很简单,步骤2调用了AdaptiveRecvByteBufAllocator.Handle的record(int actualReadBytes)方法,它可以根据本次接受的数据量动态预测下一个缓冲区容量大小。步骤3传播readComplete事件,若没有进行重写的话,会再次调用channel.read方法, 进而调用unsafe.read方法。
清除感兴趣事件
当readPengind为false且channel设置了非自动读时,清除感兴趣事件,具体实现是将readInterestOp取反后,与selectionKey的interestop取与。
两种Channel的类比关系
在这张图上可以看出来NioServerSocketChannel与NioSocketChannel呈现出轴对称的倾向。这种良好的类继承关系使得netty服务端与客户端的代码复用性很高。我们看一下AbstractChannel与AbstractNioChannel的构造方法
protected AbstractChannel(Channel parent) {
this.parent = parent;
id = newId();
unsafe = newUnsafe();
pipeline = newChannelPipeline();
}
protected AbstractNioChannel(Channel parent, SelectableChannel ch, int readInterestOp) {
super(parent);
this.ch = ch;
this.readInterestOp = readInterestOp;
try {
ch.configureBlocking(false);
} catch (IOException e) {
try {
ch.close();
} catch (IOException e2) {
logger.warn(
"Failed to close a partially initialized socket.", e2);
}
throw new ChannelException("Failed to enter non-blocking mode.", e);
}
}
AbstractChannel中的newUnsafe方法是抽象的,其主要实现类就是图中的NioMessageUnsafe和NioByteUnsafe,分别对应服务端和客户端。Channel对于IO事件的读写在底层都会委托给Unsafe对象。netty将OP_ACCEPT和OP_READ都视为读事件也是为了尽可能复用代码。关于pipeline,将在下一小节讲述。AbstractNioChannel的入参也会根据服务端与客户端有所不同,其中NioServerSocketChannel的parent为null,NioSocketChannel的parent为创建它的NioServetSocketChannel。channel分别是jdk的ServerSocketchannel和SocketChannel,readInterestOp分别是OP_ACCEPT和OP_READ。此外两者均设置了非阻塞模式。
感想
在服务端接入新连接这里,可以看到netty通过良好的继承关系实现了多态,这带来了良好的代码复用性,但也给源码阅读带来了很大的困扰。可以与服务端启动一节多多类比,才能更好的体会netty封装的目的。