一、组件
- 一个 EventLoopGroup 包含一个或者多个 EventLoop ;
- 一个 EventLoop 在它的生命周期内只和一个 Thread 绑定;
- 所有由 EventLoop 处理的 I/O 事件都将在它专有的 Thread 上被处理;
- 一个 Channel 在它的生命周期内只注册于一个 EventLoop ;
- 一个 EventLoop 可能会被分配给一个或多个 Channel 。
二、其他
Netty中所有的 I/O 操作都是异步的。一个操作可能不会立即返回,所以我们需要一种用于在之后的某个时间点确定其结果的方法。为此,Netty提供了ChannelFuture接口,其 addListener() 方法注册了一个 ChannelFutureListener ,以便在某个操作完成时(无论是否成功)得到通知。
可以将 ChannelFuture 看作是将来要执行的操作的结果的占位符。它究竟什么时候被执行则可能取决于若干的因素,因此不可能准确地预测,但是它一定会被执行。此外,所有属于同一个 Channel 的操作都被保证其将以它们被调用的顺序被执行。
-
, ChannelHandler它充当了所有
处理入站和出站数据的应用程序逻辑的容器。 可专门用于几乎任何类型的动作,例如将数据从一种格式转换为另外一种格式,或者处理转换过程中所抛出的异常。
业务逻辑通常驻留在一个或者多个 ChannelInboundHandler 中。
ChannelPipeline 提供了 ChannelHandler 链的容器,并定义了用于在该链上传播入站和出站事件流的 API。当 Channel 被创建时,它会被自动地分配到它专属的 ChannelPipeline 。
ChannelHandler 安装到 ChannelPipeline 中的过程:
(1) 一个 ChannelInitializer 的实现被注册到了 ServerBootstrap 中
(2) 当 ChannelInitializer.initChannel() 方法被调用时, ChannelInitializer将在 ChannelPipeline 中安装一组自定义的 ChannelHandler ;
(3)ChannelInitializer将它自己从 ChannelPipeline 中移除。
使得事件流经 ChannelPipeline 是 ChannelHandler 的工作,它们是在应用程序的初始化或者引导阶段被安装的。这些对象接收事件、执行它们所实现的处理逻辑,并将数据传递给链中的下一个 ChannelHandler 。它们的执行顺序是由它们被添加的顺序所决定的。
事件的运动方向是从客户端到服务器端,那么我们称这些事件为出站的,反之则称为入站的。
在 Netty 中,有两种发送消息的方式。你可以直接写到 Channel 中,也可以写到和 ChannelHandler 相关联的 ChannelHandlerContext 对象中。前一种方式将会导致消息从 ChannelPipeline 的尾端开始流动,而后者将导致消息从 ChannelPipeline 中的下一个 ChannelHandler 开始流动。
适配器:ChannelHandlerAdapter、 ChannelInboundHandlerAdapter、ChannelOutboundHandlerAdapter
SimpleChannelInboundHandler
-
有 两 种 类 型 的 引 导 : 一 种 用 于 客 户 端 ( 简 单 地 称 为 Bootstrap ), 而 另 一种( ServerBootstrap )用于服务器。无论你的应用程序使用哪种协议或者处理哪种类型的数据,唯一决定它使用哪种引导类的是它是作为一个客户端还是作为一个服务器。
服务器需要两组不同的 Channel 。第一组将只包含一个 ServerChannel ,代表服务器自身的已绑定到某个本地端口的正在监听的套接字。而第二组将包含所有已创建的用来处理传入客户端连接(对于每个服务器已经接受的连接都有一个)的 Channel 。
三、组件
-
Channel 的正常生命周期状态发生改变时,将会生成对应的事件。这些事件将会被转发给 ChannelPipeline 中的 ChannelHandler ,其可以随后对它们做出响应。
-
在 ChannelHandler被添加到 ChannelPipeline 中或者被从 ChannelPipeline 中移除时会调用这些操作。这些方法中的每一个都接受一个 ChannelHandlerContext 参数。
-
ChannelInboundHandler ——处理入站数据以及各种状态变化;
这些方法将会在数据被接收时或者与其对应的 Channel 状态发生改变时被调用。
-
ChannelOutboundHandler ——处理出站数据并且允许拦截所有的操作。
ChannelOutboundHandler 的一个强大的功能是可以按需推迟操作或者事件,这使得可以通过一些复杂的方法来处理请求。
ChannelOutboundHandler 中的大部分方法都需要一个ChannelPromise 参数,以便在操作完成时得到通知。 ChannelPromise 是 ChannelFuture 的一个子类,其定义了一些可写的方法,如 setSuccess() 和 setFailure() ,从而使 ChannelFuture 不可变 。
每一个新创建的 Channel 都将会被分配一个新的 ChannelPipeline 。这项关联是永久性的;
通常 ChannelPipeline 中的每一个 ChannelHandler 都是通过它的 EventLoop (I/O 线程)来处理传递给它的事件的。
(1)ChannelPipeline 保存了与 Channel 相关联的 ChannelHandler ;
(2)ChannelPipeline 可以根据需要,通过添加或者删除 ChannelHandler 来动态地修改;
(3)ChannelPipeline 有着丰富的 API 用以被调用,以响应入站和出站事件。ChannelHandlerContext 代表了 ChannelHandler 和 ChannelPipeline 之间的关
联,每当有 ChannelHandler 添加到 ChannelPipeline 中时,都会创建ChannelHandlerContext 。 ChannelHandlerContext 的主要功能是管理它所关联的 ChannelHandler 和在同一个 ChannelPipeline 中的其他 ChannelHandler 之间的交互。ChannelHandler 可 以 通 知 其 所 属 的 ChannelPipeline 中 的 下 一 个ChannelHandler ,甚至可以动态修改它所属的 ChannelPipeline 。
ChannelHandlerContext 和 ChannelHandler 之间的关联(绑定)是永远不会改
变的,所以缓存对它的引用是安全的;
相对于其他类的同名方法, ChannelHandlerContext的方法将产生更短的事件流,应该尽可能地利用这个特性来获得最大的性能。
因为一个 ChannelHandler 可以从属于多个 ChannelPipeline ,所以它也可以绑定到多个 ChannelHandlerContext 实例。对于这种用法指在多个 ChannelPipeline 中共享同一个 ChannelHandler ,对应的 ChannelHandler 必须要使用 @Sharable 注解标注;否则,试图将它添加到多个 ChannelPipeline 时将会触发异常。
只应该在确定了你的 ChannelHandler 是线程安全的时才使用 @Sharable 注解。
在多个 ChannelPipeline 中安装同一个 ChannelHandler的一个常见的原因是用于收集跨越多个 Channel 的统计信息。
四、异常
入站异常处理
ChannelHandler.exceptionCaught() 的默认实现是简单地将当前异常转发给ChannelPipeline 中的下一个 ChannelHandler ;如果异常到达了 ChannelPipeline 的尾端,它将会被记录为未被处理;
要想定义自定义的处理逻辑,你需要重写 exceptionCaught() 方法。然后你需要决定是否需要将该异常传播出去。出站异常
每个出站操作都将返回一个 ChannelFuture 。注册到 ChannelFuture 的 Channel-
FutureListener 将在操作完成时被通知该操作是成功了还是出错了。
几乎所有的 ChannelOutboundHandler 上的方法都会传入一个 ChannelPromise
的实例。作为 ChannelFuture 的子类, ChannelPromise 也可以被分配用于异步通
知的监听器。但是, ChannelPromise 还具有提供立即通知的可写方法:
ChannelPromise setSuccess()、ChannelPromise setFailure(Throwable cause);