Channel相关
Channel
生命周期
状态 | 描述 |
---|---|
ChannelUnregistered | Channel 已经被创建,但还未注册到EventLoop |
ChannelRegistered | Channel 已经被注册到了EventLoop |
ChannelActive | Channel 处于活动状态(已经连接到它的远程节点)。它现在可以接收和发送数据了 |
ChannelInactive | Channel 没有连接到远程节点 |
ChannelHandler
生命周期
类型 | 描述 |
---|---|
handlerAdded | 当把ChannelHandler 添加到ChannelPipeline 中时被调用 |
handlerRemoved | 当从ChannelPipeline 中移除ChannelHandler 时被调用 |
exceptionCaught | 当处理过程中在ChannelPipeline 中有错误产生时被调用 |
ChannelInboundHandler
- 入站消息操作
类型 | 描述 |
---|---|
channelRegistered | 当Channel 已经注册到它的EventLoop 并且能够处理I/O时被调用 |
channelUnregistered | 当Channel 从它的EventLoop 注销并且无法处理任何I/O时被调用 |
channelActive | 当Channel 处于活动状态时被调用;Channel 已经连接/绑定并且已经就绪channelInactive |
channelReadComplete | 当Channel 上的一个读操作完成时被调用 |
channelRead | 当从Channel 读取数据时被调用 |
ChannelWritabilityChanged | 当Channel 的可写状态发生改变时被调用。用户可以确保写操作不会完成得太快(以避免发生OutOfMemoryError )或者可以在Channel 变为再次可写时恢复写入。可以通过调用Channel 的isWritable() 方法来检测Channel 的可写性。与可写性相关的阈值可以通过Channel.config(). setWriteHighWaterMark() 和Channel.config().setWriteLowWaterMark() 方法来设置 |
userEventTriggered | 当ChannelnboundHandler.fireUserEventTriggered() 方法被调用时被调用,因为一个POJO被传经了ChannelPipeline |
需要注意的是 在channelRead方法里面需要显式释放ByteBuf
@Overridepublic void channelRead(ChannelHandlerContext ctx, Object msg) { ← -- 丢弃已接收的消息 ReferenceCountUtil.release(msg);}
SimpleChannelInboundHandler 会自动释放资源
ChannelOutboundHandler
- 出站消息操作
类型 | 描述 |
---|---|
bind(ChannelHandlerContext,SocketAddress,ChannelPromise) | 当请求将Channel 绑定到本地地址时被调用 |
connect(ChannelHandlerContext,SocketAddress,SocketAddress,ChannelPromise) | 当请求将Channel 连接到远程节点时被调用 |
disconnect(ChannelHandlerContext,ChannelPromise) | 当请求将Channel 从远程节点断开时被调用 |
close(ChannelHandlerContext,ChannelPromise) | 当请求关闭Channel 时被调用 |
deregister(ChannelHandlerContext,ChannelPromise) | 当请求将Channel 从它的EventLoop 注销时被调用 |
read(ChannelHandlerContext) | 当请求从Channel 读取更多的数据时被调用 |
flush(ChannelHandlerContext) | 当请求通过Channel 将入队数据冲刷到远程节点时被调用 |
write(ChannelHandlerContext,Object,<br>``ChannelPromise) | 当请求通过Channel 将数据写到远程节点时被调用 |
ChannelHandlerAdapter
ResourceLeakDetector
通过分配1%的采样来检测内存泄漏
- 创建ByteBuf时调用了track0(obj)方法,传入的obj就是创建的ByteBuf对象。
- track0(obj)方法内做了2件事a. 创建一个弱引用对象,绑定上面传入的ByteBuf对象和一个全局的弱引用队列refQueue。b. 把这个弱引用对象加入到另一个全局集合allLeaks里面。
- ByteBuf对象用完了,正常情况会调用release()方法回收堆外内存,同时release()方法中调用了弱引用对象DefaultResourceLeak的close()方法,从allLeaks集合里面把这个弱引用对象移除。如果开发者忘记调用release()方法,则allLeaks集合里还会存在这个弱引用对象。
- 一段时间后,ByteBuf对象被GC回收,此时会触发一个操作:ByteBuf对象所绑定的弱引用对象被加入到refQueue中。5.下一次创建ByteBuf时又调用了track0(obj)方法,把refQueue和allLeaks这俩集合一对比,既存在于refQueue(说明ByteBuf用完了且已经被GC回收),又存在于allLeaks(说明没调用release释放内存),表明存在内存泄漏
XXTrafficShapingHandler
通过指定一个限制速度,读取或写入时进行计算,如果当前速度超限,会让生产者或者消费者等待一段时间后,再进行读取写入
ChannelPipeline
拦截流经 Channel 的入站和出站时间的ChannelHandler 示例链
修改
名称 | 描述 |
---|---|
addFirst addBefore addAfter addLast | 将一个ChannelHandler 添加到ChannelPipeline 中 |
remove | 将一个ChannelHandler 从ChannelPipeline 中移除 |
replace | 将ChannelPipeline 中的一个ChannelHandler 替换为另一个Channel- Handler |
访问 ChannelHandler
名称 | 描述 |
---|---|
get | 通过类型或者名称返回ChannelHandler |
context | 返回和ChannelHandler 绑定的ChannelHandlerContext |
names | 返回ChannelPipeline 中所有ChannelHandler 的名称 |
出入站事件
ChannelHandlerContext
代表了 ChannelHandler 与 ChannelPipeline 之间的关联
这个类提供的一些访问在 Channel 与 ChannelPipeline 上也有
使用该类的目的是产生更短的事件流以及为了更高的性能