1. Channel、EventLoop和ChannelFuture

 Channel、EventLoop 和 ChannelFuture 类在 Netty  中被结合在一起，可以认为是 Netty 网络抽象的代表：

Channel:Socket

EventLoop:控制流、多线程处理、并发

ChannelFuture:异步通知

1.1 Channel 接口

        基本的 I/O 操作（bind()、connect()、read()和 write()）依赖于底层网络传输所提供的原语。在基于 Java 的网络编程中，其基本的构造是 class Socket。Netty 的 Channel 接口所提供的 API，大大地降低了直接使用 Socket 类的复杂性。此外，Channel 也是拥有许多预定义的、专门化实现的广泛类层次结构的根，下面是一个简短的部分清单：

 EmbeddedChannel

 LocalServerChannel

 NioDatagramChannel

 NioSctpChannel

 NioSocketChannel

1.2 EventLoop接口

        EventLoop 定义了 Netty 的核心抽象，用于处理连接的生命周期中所发生的事件。图 1-1在高层次上说明了 Channel、EventLoop、Thread 以及 EventLoopGroup 之间的关系

图1-1 Channel、ChannelFuture、EventLoop (图片来源Netty实战)

具体关系如下:

 一个 EventLoopGroup 包含一个或者多个 EventLoop；

 一个 EventLoop 在它的生命周期内只和一个 Thread 绑定；

 所有由 EventLoop 处理的 I/O 事件都将在它专有的 Thread 上被处理；

 一个 Channel 在它的生命周期内只注册于一个 EventLoop；

 一个 EventLoop 可能会被分配给一个或多个 Channel。

注意，在这种设计中，一个给定 Channel 的 I/O 操作都是由相同的 Thread 执行的，实际

上消除了对于同步的需要。

1.3  ChannelFuture 接口

        Netty 中所有的 I/O 操作都是异步的。因为一个操作可能不会立即返回，所以我们需要一种用于在之后的某个时间点确定其结果的方法。为此，Netty 提供了ChannelFuture 接口，其 addListener()方法可以注册一个 ChannelFutureListener，以便在某个操作完成时（无论是否成功）得到通知。 ChannelFuture 可以看作是将来要执行的操作的结果的占位符。它究竟什么时候被执行则可能取决于若干的因素，因此不可能准确地预测，但是可以肯定的是它将会被执行。此外，所有属于同一个 Channel 的操作都被保证其将以它们被调用的顺序被执行。

2. ChannelHandler 和 ChannelPipeline

2.1 ChannelHandler 接口

        Netty 的主要组件是 ChannelHandler，它充当了所有处理入站和出站数据的应用程序逻辑的容器。举例来说，ChannelInboundHandler 是一个你将会经常实现的子接口。这种类型的ChannelHandler 接收入站事件和数据，这些数据随后将会被你的应用程序的业务逻辑所处理。当你要给连接的客户端发送响应时，也可以从 ChannelInboundHandler 冲刷数据。你的应用程序的业务逻辑通常驻留在一个或者多个 ChannelInboundHandler 中。

2.2 ChannelPipeline 接口

        ChannelPipeline 提供了 ChannelHandler 链的容器，并定义了用于在该链上传播入站和出站事件流的 API。当 Channel 被创建时，它会被自动地分配到它专属的 ChannelPipeline。ChannelHandler 安装到 ChannelPipeline 中的过程如下所示：

①一个ChannelInitializer的实现被注册到了ServerBootstrap中 ；

② 当 ChannelInitializer.initChannel()方法被调用时，ChannelInitializer；

③将在 ChannelPipeline 中安装一组自定义的 ChannelHandler；

④ChannelInitializer 将它自己从 ChannelPipeline 中移除；

        ChannelHandler 是专为支持广泛的用途而设计的，可以将它看作是处理往来 Channel�Pipeline 事件（包括数据）的任何代码的通用容器。图 2-2 说明了这一点，其展示了从ChannelHandler 派生的 ChannelInboundHandler 和 ChannelOutboundHandler 接口。

图2-2 ChannelHander类的层次结构(图片来自Netty实战)

2.3 编码器和解码器

        当你通过 Netty 发送或者接收一个消息的时候，就将会发生一次数据转换。入站消息会被解码；也就是说，从字节转换为另一种格式，通常是一个 Java 对象。如果是出站消息，则会发生相反方向的转换：它将从它的当前格式被编码为字节。这两种方向的转换的原因很简单：网络数据总是一系列的字节。当你通过 Netty 发送或者接收一个消息的时候，就将会发生一次数据转换。入站消息会被解码；也就是说，从字节转换为另一种格式，通常是一个 Java 对象。如果是出站消息，则会发生相反方向的转换：它将从它的当前格式被编码为字节。这两种方向的转换的原因很简单：网络数据总是一系列的字节。严格地说，其他的处理器也可以完成编码器和解码器的功能。但是，正如有用来简化ChannelHandler 的创建的适配器类一样，所有由 Netty 提供的编码器/解码器适配器类都实现了 ChannelOutboundHandler 或者 ChannelInboundHandler 接口。你将会发现对于入站数据来说，channelRead 方法/事件已经被重写了。对于每个从入站Channel 读取的消息，这个方法都将会被调用。随后，它将调用由预置解码器所提供的 decode()方法，并将已解码的字节转发给 ChannelPipeline 中的下一个 ChannelInboundHandler。出站消息的模式是相反方向的：编码器将消息转换为字节，并将它们转发给下一个ChannelOutboundHandler。

3. 引导

        Netty 的引导类为应用程序的网络层配置提供了容器，这涉及将一个进程绑定到某个指定的端口，或者将一个进程连接到另一个运行在某个指定主机的指定端口上的进程。通常来说，我们把前面的用例称作引导一个服务器，后面的用例称作引导一个客户端。虽然这个术语简单方便，但是它略微掩盖了一个重要的事实，即“服务器”和“客户端”实际上表示了不同的网络行为；换句话说，是监听传入的连接还是建立到一个或者多个进程的连接。有两种类型的引导：一种用于客户端（简单地称为 Bootstrap），而另一种（ServerBootstrap）用于服务器。无论你的应用程序使用哪种协议或者处理哪种类型的数据，唯一决定它使用哪种引导类的是它是作为一个客户端还是作为一个服务器。表 3-1 比较了这两种类型的引导类。

图3-1 Bootstrap比较(图片来源Netty实战)