Netty-ChannelHandler-ChannelPipeline

摘要：只有在详尽的测试之后才应设置为这值使用的默认采样率检测并报告任何发现的泄漏。这是默认级别，适合绝大部分情况使用默认的采样率，报告所发现的任何的泄漏以及对应的消息被访问的位置类似于但是其将会对每次对消息的访问都进行采样。

一般Channel的生命周期顺序ChannelRegistered -> ChannelActive -> ChannelInactive -> ChannelUnregistered。

当Channel的状态发生变化时，将会生成对应的事件。与此同时，这些事件会被转发给ChannelPipeline中的ChannelHandler。

ChannelHandler定义的生命周期操作，在ChannelHandler被添加到ChannelPipeline中或者被从ChannelPipeline中移除时会调用这些方法。这些方法中都可以接受一个ChannelHandlerContext参数。

Netty中定义了下面两个重要的ChannelHandler接口：

ChannelInboundHandler——处理入站数据以及各种状态变化

CHannelOutboundHandler——处理出站数据并且允许拦截所有的操作

当某个ChannelInboundHandler的实现重写channelRead()方法时，它将负责显示地释放与池化的ByteBuf实例相关的内存。ReferenceCountUtil.release()

Netty会使用WARN级别的日志消息记录未释放的资源，但是以这种方式管理资源可能非常繁琐，Netty采用SimpleChannelInboundHandler来简化这种操作。

出站操作和数据将由ChannelOutboundHandler处理。它的方法将被Channel、ChannelPipeline以及ChannelHandlerContext调用。

ChannelOutboundHandler可以按需推迟操作或者事件。

ChannelOutboundHandler中的大部分方法都需要一个ChannelPromise参数，方便在操作完成时获取通知。ChannelPromise时ChannelFuture的一个子类，定义了一些可写方法，如setSuccess()和setFailure()方法

ChannelInboundHandlerAdapter和ChannelOutboundHandlerAdapter两个适配器分别提供了ChannelInboundHandler和ChannelOutboundHandler的基本实现。通过扩展抽象类ChannelHandlerAdapter，它们获得了它们共同的超接口ChannelHandler的方法。

ChannelHandlerAdapter提供了isSharable()，如果其对应的实现被注解标注为Sharable，这方法将返回true，表示它可以被添加到多个ChannelPipeline。

ChannelInboundHandlerAdapter和ChannelOutboundHandlerAdapter中的方法体调用了其相关联的ChannelHandlerContext上的等效方法，从而将事件转发到了ChannelPipeline中的下一个ChannelHandler中。

Netty目前定义了4种泄露检测级别：

java -Dio.netty.leakDetectionLevel=ADVANCED

如果一个消息被消费或者丢弃了，并且没有传递给ChannelPipeline中的下一个ChannelOutboundHandler，那么用户就有责任调用ReferenceCountUtil.release()。如果消息到达了实际的传输层，那么当它被写入时或者Channel关闭时，都将被自动释放。

每一个新创建的Channel都将会被分配一个新的ChannelPipeline。这项关联是永久性的；Channel既不能附加另外一个ChannelPipeline，也不能分离当前的。

根据事件的起源，事件将会被ChannelInboundHandler或者ChannelOutboundHandler处理。随后，会调用ChannelHandlerContext实现，它将被转发给同一超类型的下一个ChannelHandler。

ChannelHandlerContext使ChannelHandler能够和它的ChannelPipeline以及其他的ChannelHandler交互。ChannelHandler可以通知其所属的ChannelPipeline中的下一个ChannelHandler，甚至可以动态修改它所属的ChannelPipeline。

在ChannelPipeline传播事件时，它会测试ChannelPipeline中的下一个ChannelHandler的类型是否和事件的运动方向相匹配。如果不匹配，ChannelPipeline将跳过该ChannelHandler并前进到下一个，直到它找到和该事件所期望的方向相匹配的为止。（ChannelHandler可以同时实现ChannelInboundHandler和ChannelOutboundHandler接口）

ChannelHandler可以通过添加、删除或者替换其他的ChannelHandler来实时地修改ChannelPipeline的布局。

ChannelPipeline的API公开了用于调用入站和出站操作的附加方法，用于通知ChannelInboundHandler在ChannelPipeline中所发生的事件。

ChannelPipelin的出站操作

ChannelPipeline保存了与Channel相关联的ChannelHandler

ChannelPipeline可以根据需要，通过添加或者删除ChannelHandler来动态修改

ChannelPipeline有着丰富的API调用，以响应入站和出站事件

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

ChannelHandlerContext有很多方法，其中一些方法也存在于Channel和ChannelPipeline本身上。如果调用Channel或者ChannelPipeline上的方法，它们将沿着整个ChannelPipeline进行传播，而调用ChannelHandlerContext上的相同方法，则从当前所关联的ChannelHandler开始，并且只会传播给位于该ChannelHandler的下一个能够处理该事件的ChannelHandler。

ChannelHanlderContext和ChannelHandler之间的关联是永远不会改变的，所以缓存对它的引用是安全的

ChannelHandlerContext上的方法产生的事件流更短，应该利用这个特性尽可能的获得最大的性能

让ChannePipeline从某个特定的点开始传播的原因：

为了减少将事件传经对它不感兴趣的ChannelHandler所带来的开销

为了减少将事件传经那些可能会对它感兴趣的ChannelHandler

要想调用从某个特定的ChannelHandler开始处理的过程，必须获取到在(ChannelPipeline)该ChannelHandler之前的hannelHandler所关联的ChannelHandlerContext。这个ChannelHandlerContext将调用和它所关联的ChannelHandler之后的ChannelHandler。

一个ChannelHandler可以从属于多个ChannelPipeline，所以它(同一个ChannelHandler)也可以绑定到多个ChannelHandlerContext实例。用于这种用法的ChannelHandler必须使用@Shareable注解标注；否则将它添加到多个ChannelPipeline时将会触发异常。显而易见，为了安全地被用于多个并发的Channel(即连接)，这样的ChannelHandler必须是线程安全的。

为何要共享一个ChannelHandler？
在多个ChannelPipeline中安装同一个ChannelHandler的一个常见原因是用于收集跨越多个Channel的统计信息。

如果在处理入站事件的过程中有异常被抛出，那么它将从它在ChannelInboundHandler里被触发的那一点开始流经ChannelPipeline。如果想要处理这种类型的入站异常，必须在你的ChannelInboundHandler中重写exceptionCaught(ChannelHandlerContext,Throwable)

异常会按照入站方向流动，所以一般处理异常的逻辑通常都在最后一个ChannelInboundHandler中实现

ChannelHandler.exceptionCaught()的默认实现是简单的将当前异常转发给ChannelPipeline中的下一个ChannelHandler

如果异常到达了ChannelPipeline的尾端，它将会被记录为未被处理

要想定义自定义的处理逻辑，你需要重写exceptionCaught()方法，然后决定是否将该异常传播出去。

用于处理出站操作中的正常完成以及异常的选项，都基于以下的通知机制：

每个出站操作都返回一个ChannelFuture。注册到ChannelFuture的ChannelFutureListener将在操作完成时被通知该操作是成功了还是出错了。

几乎所有的ChannelOutboundHandler上的方法都会传入一个ChannelPromise的实例。作为ChannelFuture的子类，ChannelPromise也可以被分配用于异步通知的监听器。

添加ChannelFuturListener只需要调用ChannelFuture实例上的addListener(ChannelFutureListener)方法，并且有两种不同的方式去实现。第一种是调用出站操作(如write方法)所返回的ChanneFuture上的addListener方法；第二种方式是将ChannelFutureListener添加到即将作为参数传递给ChannelOutboundHandler的方法的ChannelPromise

通过调用ChannelPromise上的setSuccess和setFailure方法，可以使一个操作的状态在ChannelHandler的方法返回给其调用者时即刻被感知到。