Channel 的生命周期

1. ChannelUnregistered：Channel 已经被创建，但还未注册到 EventLoop
2. ChannelRegistered：Channel 已经被注册到了 EventLoop
3. ChannelActive：Channel 处于活动状态（已经连接到它的远程节点）。现在可以接收和发送数据了

4. ChannelInactive：Channel 没有连接到远程节点

   
   
   image.png

ChannelHandler 的生命周期

1. handlerAdded：当把 ChannelHandler 添加到 ChannelPipeline 中时被调用
2. handlerRemoved：当从 ChannelPipeline 中移除 ChannelHandler 时被调用
3. exceptionCaught：当处理过程中在 ChannelPipeline 中有错误产生时被调用

ChannelHandler 定义了两个重要子接口

• ChannInboundHandler处理入站数据以及各种状态变化
• ChannelOutboundHandler处理出站数据并且允许拦截所有的操作

ChannelInboundHandler的生命周期方法

1. channelRegistered：当 Channel 已经注册到它的 EventLoop 并且能够处理IO时被调用
2. channelUnregistered：当 Channel 从它的 EventLoop 注销并且无法处理任何IO时被调用
3. channelActive：当 Channel 处于活动状态时被调用；Channel已经连接、绑定并且已经就绪
4. channelInactive：当 Channel 离开活动状态并且不再连接它的远程节点时被调用
5. channelReadComplete：当 Channel 上的一个读操作完成时被调用
6. channelRead：当从 Channel 读取数据时被调用
7. channelWritabilityChanged：当 Channel 的可写状态发生改变时被调用。用户可以确保写操作不会完成得太快或者可以在 Channel 变为再次可写时恢复写入。可以通过调用 Channel 的 isWritable 方法来检测 Channel 的可写性。与可写性相关的阈值可以通过 Channel.config().setWriteHighWaterMark 和 Channel.config().setWriteLowWaterMark 方法来设置
8. userEventTriggered：当ChannelInboundHandler.fireUserEventTriggered方法被调用时调用，因为一个POJO 被传经了 ChannelPipeline

当ChannelInboundHandler的实现重写channelRead方法时，将显式地释放与池化的 ByteBuf 实例相关的内存。可调用ReferenceCountUtil.release(msg)来丢弃已经接收的消息。通过继承SimpleChannelInboundHandler，重写的channelRead0方法会自动释放资源无需显式指定

ChannelOutboundHandler接口方法，这些方法中大都需要一个ChannelPromise参数，以便在操作完成时得到通知，ChannelPromise是ChannelFuture的一个子类，其定义了一些可写的方法，如setSuccess，setFailure

1. bind：当请求将 Channel 绑定到本地地址时被调用
2. connect：当请求将 Channel 连接到远程节点时被调用
3. disconnect：当请求将 Channel 从远程节点断开时被调用
4. close：当请求关闭 Channel 时被调用
5. deregister：当请求将 Channel 从它的 EventLoop 注销时被调用
6. read：当请求从 Channel 读取更多的数据时被调用
7. flush：当请求通过 Channel 将入队数据冲刷到远程节点时被调用
8. write：当请求通过 Channel 将数据写到远程节点时被调用

ChannelHandlerAdapter抽象类实现了ChannelHander接口中ChannelInboundHandler和ChannelOutboundHandler的共同方法，ChannelInboundHandlerAdapter和ChannelOutboundHandlerAdapter中提供的方法体调用了相关联的ChannelHandlerContext上的等效方法，从而将事件转发到ChannelPipeline中的下一个ChannelHandler中

ResourceLeakDetector可以对应用程序的缓冲区分配做大约1%的采样来检测内存泄漏，Netty定义的泄漏检测级别java -Dio.netty.leakDetectionLevel=ADVANCED

• DISABLED，禁用泄漏检测
• SIMPLE，使用1%的默认采样率检测并报告任何发现的泄漏（默认）
• ADVANCED，使用默认采样率，报告所发现的任何的泄漏以及对应的消息被访问的位置
• PARANOID，类似于ADVANCED，但是其将会对每次对消息的访问都进行采样，这对性能将会有很大的影响，应该只在调试阶段使用
  ChannelOutboundHandler的write方法，中释放资源后，还需要promise.setSuccess通知数据已经被处理了

ChannelPipeline传播事件时，会测试下一个ChannelHandler的类型是否和事件的运用方向相匹配（出入站类型），如果不匹配，ChannelPipeline将跳过该ChannelHandler并前进到下一个，知道和该事件所期 望的方向相匹配为止

ChannelPipeline可通过添加、删除或者替换其他ChannelHandler来实时的修改ChannelPipeline的布局，get可以通过类型或者名称返回ChannelHandler，context返回和ChannelHandler绑定的ChannelHandlerContext，names返回ChannelPipeline中所有ChannelHandler的名称

ChannelPipeline的fireXXX方法会调用下一个ChannelHandler的相关方法来进行触发事件

ChannelHandlerContext具有丰富的事件处理API，使得ChannelHandler能够和它的ChannelPipeline以及其他的ChannelHandler交互，他们的关系如下

image.png

可以在ChannelHandler中缓存ctx的引用便于之后调用，时刻需要注意是否是线程安全的 @Sharable

入站异常将从它在ChannelInboundHandler里被触发的那一点开始流经ChannelPipeline，可以重写exceptionCaught来进行处理

• hannelHandler.exceptionCaught的默认实现是简单地将当前异常转发给ChannelPipeline中的下一个ChannelHandler
• 如果异常到达了ChannelPipeline的尾端，它将会被记录为未被处理
• 要想定义自定义的处理逻辑，你需要重写exceptionCaught方法。然后你需要决定是否需要将该异常传播出去

出站异常的处理都基于通知机制。在返回的ChannelFuture实例上执行addListener方法（如write方法返回的ChannelFuture）或者在ChannelHandler的方法中的ChannelPromise对象

• 每个出站操作都将返回一个ChannelFuture，注册到ChannelFuture的ChannelFutureListener将在操作完成时被通知该操作是成功了还是出错了
• 几乎所有ChannelOutboundHandler上的方法都会传入一个ChannelPromise实例，作为ChannelFuture的子类，ChannelPromise也可以被分配用于异步通知的监听器，同时也提供了立即通知的可写方法（setSuccess，setFailure）