深入分析netty（二）ChannelPipeline

最新推荐文章于 2024-06-22 11:49:43 发布

想上岸的小写

最新推荐文章于 2024-06-22 11:49:43 发布

阅读量396

点赞数

本文链接：https://blog.csdn.net/sdaujsj1/article/details/108113541

版权

文章目录

- 2. Netty大动脉ChannelPipeline
- - 2.1. ChannelPipeline

2. Netty大动脉ChannelPipeline

2.1. ChannelPipeline

2.1.1 Channel 与ChannelPipeline

相信大家都知道了，在Netty中每个Channel 都有且仅有一个ChannelPipeline 与之对应，它们的组成关系如下:

通过上图我们可以看到，一个Channel 包含了一个ChannelPipeline，而ChannelPipeline中又维护了一个由ChannelHandlerContext 组成的双向链表.这个链表的头是HeadContext,链表的尾是TailContext，并且每个ChannelHandl erContext 中又关联着一个ChannelHandler.
上面的图示给了我们一个对ChannelPipeline 的直观认识，但是实际上Netty 实现的Channel是否真的是这样的呢?我们继续用源码说话. .
在前我们已经知道了一个Channel 的初始化的基本过程，下面我们再回顾一下.
下面的代码是AbstractChannel 构造器:

protected AbstractChannel(Channel parent, ChannelId id) {
    this.parent = parent;
    this.id = id;
    unsafe = newUnsafe();
    pipeline = newChannelPipeline();
}

AbstractChannel有一个pipeline 字段，在构造器中会初始化它为Defaul tChannelPipeline的实例.这里的代码就印证了一点:每个Channel都有一个ChannelPipeline.接着我们跟踪一下DefaultChannelPipeline的初始化过程。

首先进入到Defaul tChannelPipeline 构造器中:

protected DefaultChannelPipeline(Channel channel) {
    this.channel = ObjectUtil.checkNotNull(channel, "channel");
    succeededFuture = new SucceededChannelFuture(channel, null);
    voidPromise =  new VoidChannelPromise(channel, true);

    tail = new TailContext(this);
    head = new HeadContext(this);

    head.next = tail;
    tail.prev = head;
}

可以看到，在DefaultChannelPipeline的构造方法中，将传入的channel 赋值给字段this. channel,接着又实例化了两个特殊的字段: tail与head. 这两个字段是一个双向链表的头和尾.其实在Defaul tChannelPipeline中，维护了一个以AbstractChanne lHandlexContext为节点的双向链表，这个链表是Netty 实现Pipeline 机制的关键.
head实现了Channel InboundHandler,而tail 实现了Channe l0utboundHandler接口，并且它们都实现了ChannelHandlerContext 接口，因此可以说head和tail即是一个ChannelHandler，又是一个ChannelHandlerContext.
接着看一下HeadContext的构造器:

HeadContext(DefaultChannelPipeline pipeline) {
    super(pipeline, null, HEAD_NAME, false, true);
    unsafe = pipeline.channel().unsafe();
    setAddComplete();
}

它调用了父类AbstractChanne lHandlerContext 的构造器，并传入参数inbound = false, outbound = true.

TailContext的构造器与HeadContext的相反它调用了父类AbstractChanne lHandlerContext的构造器，并传入参数inbound = true, outbound = false.
即header 是一个outboundHandler, 而tail 是一个inboundHandler，关于这一点，大家要特别注意，因为在后面的分析中，我们会反复用到inbound 和outbound 这两个属性.

2.1. 3 ChannelInitializer的添加

前面我们已经分析了Channel 的组成，其中我们了解到，最开始的时候ChannelPipeline 中含有两个Channe lHandl erContext(同时也是ChannelHandler)，但是这个Pipeline 并不能实现什么特殊的功能，因为我们还没有给它添加自定义的ChannelHandler.
通常来说，我们在初始化Bootstrap，会添加我们自定义的ChannelHandler，就以我们熟悉的
ChatClient来举例吧:

Bootstrap bootstrap = new Bootstrap();
bootstrap.group(workerGroup);
bootstrap.channel(NioSocketChannel.class);
bootstrap.option(ChannelOption.SO_KEEPALIVE,true);
bootstrap.handler(new ChannelInitializer<SocketChannel>() {
    protected void initChannel(SocketChannel socketChannel) throws Exception {
        socketChannel.pipeline().addLast(new IMDecoder());
        socketChannel.pipeline().addLast(new IMEncoder());
        socketChannel.pipeline().addLast(chatClientHandler);
    }
});
ChannelFuture channelFuture = bootstrap.connect(this.host, this.port).sync();
channelFuture.channel().closeFuture().sync();

上面代码的初始化过程，相信大家都不陌生.在调用handler时，传入了ChannelInitializer对象，它提供了一个initChannel 方法供我们初始化ChannelHandler.
那么这个初始化过程是怎样的呢?下面我们就来揭开它的神秘面纱.
ChannelInitializer实现了ChannelHandler, 那么它是在什么时候添加到ChannelPipeline中的呢?进行了一番搜索后，我们发现它是在Bootstrap.init 方法中添加到ChannelPipeline中的.
其代码如下:

void init(Channel channel) throws Exception {
    ChannelPipeline p = channel.pipeline();
    p.addLast(config.handler());

    final Map<ChannelOption<?>, Object> options = options0();
    synchronized (options) {
        for (Entry<ChannelOption<?>, Object> e: options.entrySet()) {
            try {
                if (!channel.config().setOption((ChannelOption<Object>) e.getKey(), e.getValue())) {
                    logger.warn("Unknown channel option: " + e);
                }
            } catch (Throwable t) {
                logger.warn("Failed to set a channel option: " + channel, t);
            }
        }
    }

    final Map<AttributeKey<?>, Object> attrs = attrs0();
    synchronized (attrs) {
        for (Entry<AttributeKey<?>, Object> e: attrs.entrySet()) {
            channel.attr((AttributeKey<Object>) e.getKey()).set(e.getValue());
        }
    }
}

上面的代码将handler() 返回的ChannelHandler 添加到Pipeline 中，而handler() 返回的是handler其实就是我们在初始化Bootstrap 调用handler 设置的ChannelInitializer实例，因此这里就是将ChannelInitializer 插入到了Pipeline 的末端.
此时Pipeline 的结构如下图所示:

我们刚才提到，在Bootstrap. init中会调用p. addLast()方法，将ChannelInitializer 插入到链表末端:

	@Override
    public final ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler) {
        final AbstractChannelHandlerContext newCtx;
        synchronized (this) {
            checkMultiplicity(handler);

            newCtx = newContext(group, filterName(name, handler), handler);

            addLast0(newCtx);

            // If the registered is false it means that the channel was not registered on an eventloop yet.
            // In this case we add the context to the pipeline and add a task that will call
            // ChannelHandler.handlerAdded(...) once the channel is registered.
            if (!registered) {
                newCtx.setAddPending();
                callHandlerCallbackLater(newCtx, true);
                return this;
            }

            EventExecutor executor = newCtx.executor();
            if (!executor.inEventLoop()) {
                newCtx.setAddPending();
                executor.execute(new Runnable() {
                    @Override
                    public void run() {
                        callHandlerAdded0(newCtx);
                    }
                });
                return this;
            }
        }
        callHandlerAdded0(newCtx);
        return this;
    }

private AbstractChannelHandlerContext newContext(EventExecutorGroup group, String name, ChannelHandler handler) {
    return new DefaultChannelHandlerContext(this, childExecutor(group), name, handler);
}

addLast有很多重载的方法，我们关注这个比较重要的方法就可以了。
上面的addLast 方法中，首先检查这个ChannelHandler 的名字是否是重复的，如果不重复的话，则调用newContext方法为这个Handler 创建一个对应的Defaul tChanne lHandl erContext实例，并与之关联起来(Context中有一个handler 属性保存着对应的Handler 实例).
为了添加一个handler 到pipeline 中，必须把此handler 包装成Channe lHandl erContext.
因此在，上面的代码中我们可以看到新实例化了一个newCtx 对象，并将handler作为参数传递到构造方法中.那么我们来看一下实例化的DefaultChanne lHandlerContext到底有什么玄机吧.
首先看它的构造器:

DefaultChannelHandlerContext(
        DefaultChannelPipeline pipeline, EventExecutor executor, String name, ChannelHandler handler) {
    super(pipeline, executor, name, isInbound(handler), isOutbound(handler));
    if (handler == null) {
        throw new NullPointerException("handler");
    }
    this.handler = handler;
}

Defaul tChannelHandlerContext的构造器中，调用了两个很有意思的方法: isInbound 与isOutbound，这两个方法是做什么的呢?

private static boolean isInbound(ChannelHandler handler) {
    return handler instanceof ChannelInboundHandler;
}

private static boolean isOutbound(ChannelHandler handler) {
    return handler instanceof ChannelOutboundHandler;
}

从源码中可以看到，当一个handler 实现了Channel InboundHandler接口，则isInbound 返回真;相似地，当一个handler 实现了Channe l0utboundHandler 接口，则isOutbound 就返回真.
而这两个boolean 变量会传递到父类AbstractChanne lHandlerContext中，并初始化父类的两个字段: inbound 与outbound.
那么这里的ChannelInitializer 所对应的Defaul tChanne lHandlerContext的inbound 与inbound字段分别是什么呢?那就看一下ChannelInitializer到底实现了哪个接口不就行了?
如下是ChannelInitializer的类层次结构图:

可以清楚地看到，ChannelInitializer 仅仅实现了Channel InboundHandler接口，因此这里实例化的Defaul tChanne lHandlerContext的inbound = true, outbound = false.不就是inbound 和outbound 两个字段嘛，为什么需要这么大费周章地分析一番?其实这两个字段关系到pipeline的事件的流向与分类求因此是十分关键的，不过我在这里先卖个关子，后面我们再来详细分析这两个字段所起的作用.在这里，我暂且只需要记住，ChannelInitializer所对应的Defaul tChanne lHandlerContext的inbound = true, outbound= false 即可.
当创建好Context后，就将这个Context插入到Pipeline 的双向链表中:

private void addLast0(AbstractChannelHandlerContext newCtx) {
    AbstractChannelHandlerContext prev = tail.prev;
    newCtx.prev = prev;
    newCtx.next = tail;
    prev.next = newCtx;
    tail.prev = newCtx;
}

2.1.4自定义ChannelHandler 的添加过程

前面我们已经分析了一个ChannelInitializer 如何插入到Pipeline 中的，接下来就来探讨一下ChannelInitializer 在哪里被调用，ChannelInitializer 的作用，以及我们自定义的ChannelHandler是如何插入到Pipeline 中的.
现在我们再简单地复习一下Channel的注册过程:
1、首先在AbstractBootstrap. ini tAndRegister中，通过group(). regi ster (channel),调用Multi threadEventLoopGroup. register方法
2、在MultithreadEventLoopGroup. register 中，通过next()获取一个可用的SingleThreadEventLoop，然后调用它的register

3、在SingleThreadEventLoop. register 中，通过channel. unsafe (). register(this,promise)来获取channel 的unsafe() 底层操作对象，然后调用它的register.
4、在AbstractUnsafe. register方法中，调用register0 方法注册Channel
5、在. AbstractUnsafe. register0中，调用AbstractNi oChannel#doRegister方法
6、AbstractNi oChannel. doRegister方法通过javaChannel (). register (eventLoop (). selector, 0，this) 将Channel 对应的Java NIO
SockerChannel注册到一个eventLoop 的Selector 中，并且将当前Channel作为attachment.
而我们自定义ChannelHandler 的添加过程，发生在AbstractUnsafe. register0中，在这个方法中调用了pipeline.fireChannelRegistered()方法，其实现如下:

@Override
public final ChannelPipeline fireChannelRegistered() {
    AbstractChannelHandlerContext.invokeChannelRegistered(head);
    return this;
}

再看AbstractChannelHandl erContext. invokeChannelRegistered方法:

static void invokeChannelRegistered(final AbstractChannelHandlerContext next) {
    EventExecutor executor = next.executor();
    if (executor.inEventLoop()) {
        next.invokeChannelRegistered();
    } else {
        executor.execute(new Runnable() {
            @Override
            public void run() {
                next.invokeChannelRegistered();
            }
        });
    }
}

很显然，这个代码会从head开始遍历Pipelhe 的双向链表，然后找到第一个属性inbound为true的 ChannelHandlerContext实例．想起来了没？我们在前面分析ChannelInitializer时，花了大量的笔墨来分析了inbound和outbound属性，你看现在这里就用上了．回想一下，ChannelInitializer实现了ChannelInboudllandler，因此它所对应的 ChannelllandlerContext的inbound属性就是true，因此这里返回就是 ChannelInitializer实例所对应的ChannelHandlerContext.即:

当获取到inbound的 Context后，就调用它的invokeChannelRegistered方法:

private void invokeChannelRegistered() {
    if (invokeHandler()) {
        try {
            ((ChannelInboundHandler) handler()).channelRegistered(this);
        } catch (Throwable t) {
            notifyHandlerException(t);
        }
    } else {
        fireChannelRegistered();
    }
}

我们已经强调过了，每个 ChannelHandler都与一个ChannelHandlerContext 关联，我们可以通过ChannelHandlerContext获取到对应的ChannelHandler.因此很显然了，这里handler()返回的，其实就是一开始我们实例化的 ChannelInitializer对象，并接着调用了ChannelInitializer.channelRegistered方法．看到这里，是否会觉得有点眼熟呢?ChannelInitializer.channelRegistered这个方法我们在一开始的时候已经大量地接触了，但是我们并没有深入地分析这个方法的调用过程，那么在这里读者朋友应该对它的调用有了更加深入的了解了吧

那么这个方法中又有什么玄机呢？继续看代码：

@Override
@SuppressWarnings("unchecked")
public final void channelRegistered(ChannelHandlerContext ctx) throws Exception {
    // Normally this method will never be called as handlerAdded(...) should call initChannel(...) and remove
    // the handler.
    if (initChannel(ctx)) {
        // we called initChannel(...) so we need to call now pipeline.fireChannelRegistered() to ensure we not
        // miss an event.
        ctx.pipeline().fireChannelRegistered();
    } else {
        // Called initChannel(...) before which is the expected behavior, so just forward the event.
        ctx.fireChannelRegistered();
    }
}

@SuppressWarnings("unchecked")
private boolean initChannel(ChannelHandlerContext ctx) throws Exception {
    if (initMap.putIfAbsent(ctx, Boolean.TRUE) == null) { // Guard against re-entrance.
        try {
            initChannel((C) ctx.channel());
        } catch (Throwable cause) {
            // Explicitly call exceptionCaught(...) as we removed the handler before calling initChannel(...).
            // We do so to prevent multiple calls to initChannel(...).
            exceptionCaught(ctx, cause);
        } finally {
            remove(ctx);
        }
        return true;
    }
    return false;
}

initchannel(©ctx.channel());这个方法我们很熟悉了吧，它就是我们在初始化Bootstrap时，调用handler方法传入的匿名内部类所实现的方法:

bootstrap.handler(new ChannelInitializer<SocketChannel>() {
    protected void initChannel(SocketChannel socketChannel) throws Exception {
        socketChannel.pipeline().addLast(new IMDecoder());
        socketChannel.pipeline().addLast(new IMEncoder());
        socketChannel.pipeline().addLast(chatClientHandler);
    }
});

因此当调用了这个方法后，我们自定义的 Channelllandler就插入到Pipeline 了，此时的Pipeline如下图所示:

当添加了自定义的Channellandler后，会删除 ChannelInitializer这个ChannelHandler,即"ctx.pipeline().remove(this)"，因此最后的 Pipeline如下:

好了，到了这里，我们的自定义 ChannelHandler的添加过程也分析的查不多了

2.1.5 ChannelHandler的名字

我们注意到，pipeline.addXXX都有一个重载的方法，例如addLast，它有一个重载的版本是:

ChannelPipeline addLast(String name,ChannelHandler handler);

第一个参数指定了所添加的handler的名字(更准确地说是 ChannelllandlerContext的名字，不过我们通常是以 handler作为叙述的对象，因此说成handler的名字便于理解)．那么handler的名字有什么用呢?如果我们不设置name，那么handler会有怎样的名字?

为了解答这些疑惑，老规矩，依然是从源码中找到答案.

我们还是以addLast 方法为例:

@Override
public final ChannelPipeline addLast(ChannelHandler... handlers) {
    return addLast(null, handlers);
}

这个方法会调用重载的addLast 方法:

@Override
public final ChannelPipeline addLast(EventExecutorGroup executor, ChannelHandler... handlers) {
    if (handlers == null) {
        throw new NullPointerException("handlers");
    }

    for (ChannelHandler h: handlers) {
        if (h == null) {
            break;
        }
        addLast(executor, null, h);
    }

    return this;
}

第一个参数被设置为null，我们不关心它．第二参数就是这个handler的名字．看代码可知，在添加一个handler之前，需要调用checkMultiplicity方法来确定此 handler和已添加的handler的名字重复.

2.1.6自动生成handler的名字

如果我们调用的是如下的 addLast方法
ChannelPipeline addLast(ChannelHandler… handlers);
那么Netty会调用generateName为我们的handler自动生成一个名字:

private String filterName(String name, ChannelHandler handler) {
    if (name == null) {
        return generateName(handler);
    }
    checkDuplicateName(name);
    return name;
}

private String generateName(ChannelHandler handler) {
    Map<Class<?>, String> cache = nameCaches.get();
    Class<?> handlerType = handler.getClass();
    String name = cache.get(handlerType);
    if (name == null) {
        name = generateName0(handlerType);
        cache.put(handlerType, name);
    }

    // It's not very likely for a user to put more than one handler of the same type, but make sure to avoid
    // any name conflicts.  Note that we don't cache the names generated here.
    if (context0(name) != null) {
        String baseName = name.substring(0, name.length() - 1); // Strip the trailing '0'.
        for (int i = 1;; i ++) {
            String newName = baseName + i;
            if (context0(newName) == null) {
                name = newName;
                break;
            }
        }
    }
    return name;
}

而generateName会接着调用generateNameO来实际产生一个 handler的名字:

	private static String generateName0(Class<?> handlerType) {
        return StringUtil.simpleClassName(handlerType) + "#0";
    }

自动生成的名字的规则很简单，就是handler的简单类名加上“#O"，因此我们的ChatClientHandler的名字就是"ChatClientHandler#O"

2.1.7关于Pipeline的事件传输机制

前面章节中，我们知道AbstractChannelHandlerContext中有inbound和outbound两个

boolean变量，分别用于标识Context所对应的 handler的类型，即:

1、inbound为真时，表示对应的Channelllandler实现了ChannelInboundllandler方法.
2、outbound为真时，表示对应的ChannelHlandler实现了ChannelOutboundHlandler方法.

这里大家肯定很疑惑了吧:那究竟这两个字段有什么作用呢?其实这还要从ChannelPipeline的传输的事件类型说起.
Netty的事件可以分为Inbound和Outbound事件.
inbound 事件和outbound事件的流向是不一样的，inbound 事件的流行是从下至上，而outbound刚好相反，是从上到下．并且inbound 的传递方式是通过调用相应的ChannelHandlerContext.fireIN_EVT()方法，而outbound方法的的传递方式是通过调用ChannelHandlerContext.OUT_EVT() 例如ChannellandlerContext.fireChannelRegistered()调用会发送一个 ChannelRegistered 的inbound给下一个ChannellandlerContext，而 ChannelHlandlerContext.bind调用会发送一个bind的outbound事件给下一个ChannelHandlerContext.

注意，如果我们捕获了一个事件，并且想让这个事件继续传递下去，那么需要调用Context相应的传播方法.

例如:

public void channelActive(ChannelHandlerContext ctx) throws Exception {
    this.ctx = ctx;
    IMMessage message = new IMMessage(IMP.LOGIN.getName(),System.currentTimeMillis(),this.nickName);
    sendMsg(message);
    logger.info("成功连接服务器，已执行登录动作");
    session();
}

上面的例子中，MyInboundHandler收到了一个 channelActive事件，它在处理后，如果希望将事件继续传播下去，那么需要接着调用ctx.fireChannelActive().

2.1.8 Outbound的操作(outbound operations of a channel)

Outbound事件都是请求事件(request event)，即请求某件事情的发生，然后通过Outbound事件进行通知.
Outbound事件的传播方向是tail -> customContext ->head.
我们接下来以 connect事件为例，分析一下 Outbound事件的传播机制.

首先，当用户调用了Bootstrap.connect方法时，就会触发一个Connect请求事件，此调用会触发如下调用链:
Bootstrap.connect->Bootstrap. doResolveAndConnect->Bootstrap.doResolveAndConnectO->Bootstrap.doConnect->AbstractChannel.connect
继续跟踪的话，我们就发现，AbstractChannel.connect其实由调用了
DefaultChannelPipeline.connect方法:

@Override
public final ChannelFuture connect(SocketAddress remoteAddress, SocketAddress localAddress) {
    return tail.connect(remoteAddress, localAddress);
}

可以看到，当outbound事件(这里是connect事件)传递到Pipeline后，它其实是以tail为起点开始传播的.

而tail.connect其实调用的是 AbstractChannelHandlerContext.connect方法:

@Override
public ChannelFuture connect(
        final SocketAddress remoteAddress, final SocketAddress localAddress, final ChannelPromise promise) {

    if (remoteAddress == null) {
        throw new NullPointerException("remoteAddress");
    }
    if (!validatePromise(promise, false)) {
        // cancelled
        return promise;
    }

    final AbstractChannelHandlerContext next = findContextOutbound();
    EventExecutor executor = next.executor();
    if (executor.inEventLoop()) {
        next.invokeConnect(remoteAddress, localAddress, promise);
    } else {
        safeExecute(executor, new Runnable() {
            @Override
            public void run() {
                next.invokeConnect(remoteAddress, localAddress, promise);
            }
        }, promise, null);
    }
    return promise;
}

findContextOutbound()顾名思义，它的作用是以当前Context为起点，向Pipeline中的Context双向链表的前端寻找第一个outbound属性为真的Context(即关联着ChannelOutboundHandler的 Context)，然后返回.

它的实现如下:

private AbstractChannelHandlerContext findContextOutbound() {
    AbstractChannelHandlerContext ctx = this;
    do {
        ctx = ctx.prev;
    } while (!ctx.outbound);
    return ctx;
}

当我们找到了一个 outbound 的Context后，就调用它的invokeConnect方法，这个方法中会调用 Context所关联着的 ChannelHandler的connect方法:

private void invokeConnect(SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise) {
    if (invokeHandler()) {
        try {
            ((ChannelOutboundHandler) handler()).connect(this, remoteAddress, localAddress, promise);
        } catch (Throwable t) {
            notifyOutboundHandlerException(t, promise);
        }
    } else {
        connect(remoteAddress, localAddress, promise);
    }
}

如果用户没有重写ChannelHandler的connect方法，那么会调用ChannelOutboundHandlerAdapter所实现的方法:

@Override
public void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress,
        SocketAddress localAddress, ChannelPromise promise) throws Exception {
    ctx.connect(remoteAddress, localAddress, promise);
}

我们看到，ChannelOutboundllandlerAdapter.connect仅仅调用了ctx.connect，而这个调用又回到了:

Context.connect ->Connect.findContextOutbound ->next.invokeConnect ->handler.connect ->Context.connect

这样的循环中，直到connect事件传递到DefaultChannelPipeline的双向链表的头节点，即head中.为什么会传递到head中呢?回想一下，head 实现了ChannelOutboundHlandler，因此它的 outbound属性是true.

因此当connect消息传递到head后，会将消息转递到对应的 ChannelHandler中处理，而恰因此当connect消息传递到head后，会将消息转递到对应的 ChannelHandler中处理，而恰好，head的handler()返回的就是head本身:

@Override
public ChannelHandler handler() {
    return this;
}

因此最终connect事件是在 head中处理的. head的connect事件处理方法如下:

@Override
public void connect(
        ChannelHandlerContext ctx,
        SocketAddress remoteAddress, SocketAddress localAddress,
        ChannelPromise promise) throws Exception {
    unsafe.connect(remoteAddress, localAddress, promise);
}