• ChannelHandler和ChannelPipeline
  • ChannelHandler家族
    • Channel的生命周期
    • ChannelHandler生命周期
    • ChannelInboundHandler接口
    • ChannelOutboundHandler接口
    • 资源管理
  • ChannelPipeline
    • ChannelPipeline相对论
    • 修改ChannelPipeline
    • ChannelHandler的执行和阻塞
    • 触发事件
  • ChannelHandlerContext
    • ChannelHandlerContext的高级用法

ChannelHandler和ChannelPipeline

在Netty组件中我们已经介绍了ChannelHandler和ChannelPipeline的关系，这里我们将继续深入了解这两个核心 组件的细节。在学习本章内容之前，请各位同学温习一遍Netty组件部分的内容。

ChannelHandler家族

Channel的生命周期

在Channel的生命周期中，它的状态与ChannelHandler是密切相关的，下列是Channel组件的四个状态：

Channel的生命周期如下图所示，当这些状态发生改变时，将会生成对应的事件，ChannelPipeline中的ChannelHandler 就可以及时做出处理。

ChannelHandler生命周期

ChannelHandler接口定义了其生命周期中的操作，当ChanelHandler被添加到ChannelPipeline 或从ChannelPipeline中移除时，会调用这些操作，ChannelHandler的生命周期如下：

ChannelInboundHandler接口

ChannelInboundHandler会在接受数据或者其对应的Channel状态发生改变时调用其生命周期的方法， ChannelInboundHandler的生命周期和Channel的生命周期其实是密切相关的。 以下是ChannelInboundHandler的生命周期方法：

这里有一个细节一定需要注意：当我们实现ChannelInboundHandler的channelRead方法时，请一定要记住 使用ReferenceCountUtil的release方法释放ByteBuf，这样可以减少内存的消耗，所以我们可以实现一个 ChannelHandler来完成对ByteBuf的释放，就像下面这样：

一个更好的办法是继承SimpleChannelInboundHandler，因为SimpleChannelInboundHandler已经帮我们 把与业务无关的逻辑在ChannelRead方法实现了，我们只需要实现它的channelRead0方法来完成我们的逻辑就够了：

可以看到SimpleChannelInboundHandler已经将释放资源的逻辑实现了，而且会自动调用ChannelRead0方法 来完成我们业务逻辑。

ChannelOutboundHandler接口

出站数据将由ChannelOutboundHandler处理，它的方法将被Channel，ChannelPipeline以及ChannelHandlerContext调用 （Channel，ChannelPipeline，ChannelHandlerContext都拥有write操作），以下是ChannelOutboundHandler的主要方法：

ChannelOutboundHandler的大部分方法都需要一个ChannelPromise类型的参数，ChannelPromise是 ChannelFuture的一个子接口，这样你就可以明白ChannelPromise实际的作用和ChannelFuture是一样的， 没错，ChannelPromise正是用于在ChannelOutboundHandler的操作完成后执行的回调。

资源管理

当我们使用ChannelInboundHandler的read或ChannelOutboundHandler的write操作时，我们都需要保证 没有任何资源泄露并尽可能的减少资源耗费。之前已经介绍过了ReferenceCount引用计数用于处理池化的 ByteBuf资源。 为了帮助我们诊断潜在的的资源泄露问题，Netty提供了ResourceLeakDetector，它将 对我们的Netty程序的已分配的缓冲区做大约1%的采样用以检测内存泄露，Netty目前定义了4种泄露检测级别，如下：

我们可以通过JVM启动参数来设置leakDetector的级别：

java -Dio.netty.leakDetectionLevel=ADVANCED

ChannelPipeline

在Netty组件中也介绍过了，ChannelPipeline是一系列ChannelHandler组成的拦截链，每一个新创建的Channel 都会被分配一个新的ChannelPipeline，Channel和ChannelPipeline之间的关联是持久的，无需我们干涉它们 之间的关系。

ChannelPipeline相对论

Netty总是将ChannelPipeline的入站口作为头部，出站口作为尾部，当我们通过ChannelPipeline的add方法 将入站处理器和出站处理器混合添加到ChannelPipeline后，ChannelHandler的顺序如下：

一个入站事件将从ChannelPipeline的头部（左侧）向尾部（右侧）开始传播，出站事件的传播则是与入站的传播方向 相反。当ChannelPipeline在ChannelHandler之间传播事件的时候，它会判断下一个ChannelHandler的类型 是否与当前ChannelHandler的类型相同，如果相同则说明它们是一个方向的事件， 如果不同则跳过该ChannelHandler并前进到下一个ChannelHandler，直到它找到相同类型的ChannelHandler。

修改ChannelPipeline

ChannelPipeline可以通过添加，删除和修改ChannelHandler来修改它自身的布局，这是它最基本的能力， 一下列举了ChannelPipeline的一些修改方法：

| 方法 | 描述 | | addXX | 将指定的ChannelHandler添加到ChannelPipeline中 | | remove | 将指定的ChannelHandler从ChannelPipeline中移除 | | replace | 将ChannelPipeline中指定的ChannelHandler替换成另一个ChannelHandler |

ChannelHandler的执行和阻塞

通常ChannelPipeline中的每个ChannelHandler都是通过它（ChannelPipeline）的EventLoop线程来处理 传递给他的数据的，所以我们不能去阻塞这个线程，否则会对整体的IO操作产生负面影响。 但有时候不得已 需要使用阻塞的API来完成逻辑处理，对于这种情况，ChannelPipeline的某些方法支持接受一个EventLoopGroup 类型的参数，我们可以通过自定义EventLoopGroup的方式，使ChannelHandler在我们的EventLoopGroup内处理数据。 这样一来，就可以避免阻塞线程的影响了。

触发事件

ChannelPipeline的API不仅有对ChannelHandler的增删改操作，还有对入站和出站操作的附加方法，如下：

ChannelPipeline的入站方法：

ChannelPipeline的出站方法：

ChannelHandlerContext

ChannelHandlerContext代表的是ChannelHandler和ChannelPipeline之间的关联，每当有ChannelHandler 添加到ChannelPipeline中时，都会创建ChannelHandlerContext。ChannelHandlerContext的主要功能是 管理它所关联的ChannelHandler与同一个ChannelPipeline中的其他ChannelHandler之间的交互：

ChannelHandlerContext的大部分方法和Channel和ChannelPipeline相似，但有一个重要的区别是： 调用Channel或ChannelPipeline的方法，如：

//使用Chanel write
Channel channel = ctx.channel();
ctx.write(xxx);

//使用Pipeline write
ChannelPipeline pipeline = ctx.pipeline();
pipeline.write(xxx);

，其影响是会沿着整个ChannelPipeline进行传播：

而调用ChannelHandlerContext的方法，如：

//使用ChannelContext write
ctx.write(xxx);

则是从其关联的ChannelHandler开始，并且只会传播给位于该ChannelPipeline中的下一个能够处理该事件的 ChannelHandler：

下面是一些比较重要的方法，有些和ChannelPipeline功能相似的方法就不再罗列了，各位同学可以直接查看原API。

ChannelHandlerContext的高级用法

有时候我们需要在多个ChannelPipeline之间共享一个ChannelHandler，以此实现跨管道处理（获取）数据 的功能，此时的ChannelHandler属于多个ChannelPipeline，且会绑定到不同的ChannelHandlerContext上。 在多个ChannelPipeline之间共享ChannelHandler我们需要使用 @Sharable注解，这代表着它是一个共享的 ChannelHandler，如果一个ChannelHandler没有使用@Sharable注解却被用于多个ChannelPipeline，那么 将会触发异常。 还有非常重要的一点：一个ChannelHandler被用于多个ChannelPipeline肯定涉及到多线程 数据共享的问题，因此我们需要保证ChannelHandler的方法同步。 下面是一个很好的例子：

@Sharable
public class UnsafeSharableChannelHandler extends ChannelInboundHandlerAdapter
{
    private int count;

    @Override
    public void channelRead(ChannelHandlerContext ctx,Object msg)
    {
        count++;
        System.out.println("count : " + count);
        ctx.fireChannelRead(msg);
    }
}

上面这个ChannelHandler标识了@Sharable注解，这代表它需要被用于多个ChannelPipeline之间， 但是这个ChannelHandler之中有一个不易察觉的问题： 它声明了一个实例变量count，且ChannelRead方法 不是线程安全的。 那么这个问题的后果我相信学习了多线程的同学应该都明白，一个最简单的方法 就是给修改了count的变量的方法加synchronized关键字，确保即使在多个ChannelPipeline之间共享， ChannelHandler也能保证数据一致。