Netty 4.1.7.Final

---

icon: edit
date: 2022-01-04
category:

• CategoryA
• CategoryB
  tag:
• tag A
• tag B

---

Netty 4.1.7.Final

Netty 的核心组件

• Channel
• 回调
• Future
• 事件和 ChannelHandler

简单的例子

class AceServer {
    companion object {
        @JvmStatic
        fun main(args: Array<String>) {
            val boss = NioEventLoopGroup()
            val worker = NioEventLoopGroup(4)
            val bootstrap = ServerBootstrap()
                .group(boss, worker)
                .channel(NioServerSocketChannel::class.java)
                .option(ChannelOption.SO_BACKLOG, 128)
                .childOption(ChannelOption.SO_KEEPALIVE, true)
                .option(ChannelOption.SO_RCVBUF, 1024 * 10000)
                .option(ChannelOption.SO_SNDBUF, 1024 * 10000)
                .handler(LoggingHandler(LogLevel.INFO))
                .childHandler(object : ChannelInitializer<SocketChannel>() {
                    override fun initChannel(p0: SocketChannel) {
                        p0.pipeline().addLast(StringEncoder())
                        p0.pipeline().addLast(StringDecoder())
                        p0.pipeline().addLast(object : SimpleChannelInboundHandler<String>() {
                            override fun channelRead0(p0: ChannelHandlerContext, p1: String?) {
                                println("收到客户端的消息：$p1")
                                p0.channel().writeAndFlush(p1)
                            }
                        })
                    }

                })

            val server = bootstrap.bind(8888).sync()   //绑定端口并进行同步操作
            server.addListener {
                if (it.isSuccess)
                    println("netty-im server have been bind in 8888!")
                else
                    println("netty-im server run error!")
            }
            server.channel().closeFuture().sync()
            boss.shutdownGracefully()
            worker.shutdownGracefully()
        }
    }
}

class AceClient {
    companion object {
        @JvmStatic
        fun main(args: Array<String>) {
            val boss = NioEventLoopGroup()
            val bootstrap = Bootstrap().group(boss)
                .channel(NioSocketChannel::class.java).handler(LoggingHandler(LogLevel.INFO))
                .option(ChannelOption.SO_RCVBUF, 1024 * 10000)
                .option(ChannelOption.SO_SNDBUF, 1024 * 10000)
                .handler(object : ChannelInitializer<SocketChannel>() {
                    override fun initChannel(p0: SocketChannel) {
                        p0.pipeline().addLast(StringEncoder())
                        p0.pipeline().addLast(StringDecoder())
                        p0.pipeline().addLast(object : io.netty.channel.ChannelInboundHandlerAdapter() {
                            override fun channelRead(ctx: ChannelHandlerContext, msg: Any?) {
                                println("收到服务端的消息：$msg")
                            }
                        })
                    }
                })


            val sync = bootstrap.connect("localhost", 8888).sync().addListener {
                if (it.isSuccess) println("connect success!")
            }

            thread {
                val scanner = Scanner(System.`in`)
                while (scanner.hasNextLine()) {
                    sync.channel().writeAndFlush(scanner.nextLine())
                }
            }
            sync.channel().closeFuture().sync()
            println("结束")

        }
    }
}

Channel

Channel—Socket

基本的 I/O 操作（bind()、connect()、read()和 write()）依赖于底层网络传输所提

供的原语。在基于 Java 的网络编程中，其基本的构造是 class Socket。Netty 的 Channel 接

口所提供的 API，大大地降低了直接使用 Socket 类的复杂性。此外，Channel 也是拥有许多

预定义的、专门化实现的广泛类层次结构的根，下面是一个简短的部分清单：

• EmbeddedChannel；
• LocalServerChannel；
• NioDatagramChannel；
• NioSctpChannel；
• NioSocketChannel

EventLoop

EventLoop 定义了 Netty 的核心抽象，用于处理连接的生命周期中所发生的事件。

• 一个 EventLoopGroup 包含一个或者多个 EventLoop；
• 一个 EventLoop 在它的生命周期内只和一个 Thread 绑定；
• 所有由 EventLoop 处理的 I/O 事件都将在它专有的 Thread 上被处理；
• 一个 Channel 在它的生命周期内只注册于一个 EventLoop；
• 一个 EventLoop 可能会被分配给一个或多个 Channel。

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

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

ChannelFuture

netty 中所有的 I/O 操作都是异步的。因为一个操作可能不会立即返回，所以我们需要一种用于在之后的某个时间点确定其结果的方法。为此，Netty 提供了ChannelFuture 接口，其 addListener()方法注册了一个 ChannelFutureListener，以便在某个操作完成时（无论是否成功）得到通知。

ChannelHandler

从应用程序开发人员的角度来看，Netty 的主要组件是 ChannelHandler，它充当了所有处理入站和出站数据的应用程序逻辑的容器。这是可行的，因为 ChannelHandler 的方法是

由网络事件（其中术语“事件”的使用非常广泛）触发的。事实上，ChannelHandler 可专门用于几乎任何类型的动作，例如将数据从一种格式转换为另外一种格式，或者处理转换过程中所抛出的异常。

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

ChannelPipeline

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

ChannelHandler 安装到 ChannelPipeline 中的过程如下所示：

• 一个ChannelInitializer的实现被注册到了ServerBootstrap中 ①；
• 当 ChannelInitializer.initChannel()方法被调用时，ChannelInitializer将在 ChannelPipeline 中安装一组自定义的 ChannelHandler；
• ChannelInitializer 将它自己从 ChannelPipeline 中移除。

ChannelHandler 是专为支持广泛的用途而设计的，可以将它看作是处理往来 ChannelPipeline 事件（包括数据）的任何代码的通用容器。

Handler 派生的 ChannelInboundHandler 和 ChannelOutboundHandler 接口使得事件流经 ChannelPipeline 是 ChannelHandler 的工作，它们是在应用程序的初始化或者引导阶段被安装的。这些对象接收事件、执行它们所实现的处理逻辑，并将数据传递给链中的下一个 ChannelHandler。它们的执行顺序是由它们被添加的顺序所决定。

:::tip 为什么需要适配器类

有一些适配器类可以将编写自定义的 ChannelHandler 所需要的努力降到最低限度，因为它们提

供了定义在对应接口中的所有方法的默认实现。

下面这些是编写自定义 ChannelHandler 时经常会用到的适配器类：

• ChannelHandlerAdapter
• ChannelInboundHandlerAdapter
• ChannelOutboundHandlerAdapter
• ChannelDuplexHandler

:::

SimpleChannelInboundHandler

最常见的情况是，你的应用程序会利用一个 ChannelHandler 来接收解码消息，并对该数据应用业务逻辑。要创建一个这样的 ChannelHandler，你只需要扩展基类 SimpleChannelInboundHandler，其中 T 是你要处理的消息的 Java 类型 。在这个 ChannelHandler 中， 你将需要重写基类的一个或者多个方法，并且获取一个到 ChannelHandlerContext 的引用，这个引用将作为输入参数传递给 ChannelHandler 的所有方法。

在这种类型的 ChannelHandler 中，最重要的方法是 channelRead0(ChannelHandlerContext,T)。除了要求不要阻塞当前的 I/O 线程之外，其具体实现完全取决于你。

引导

Netty 的引导类为应用程序的网络层配置提供了容器，这涉及将一个进程绑定到某个指定的端口，或者将一个进程连接到另一个运行在某个指定主机的指定端口上的进程。

通常来说，我们把前面的用例称作引导一个服务器，后面的用例称作引导一个客户端。虽然这个术语简单方便，但是它略微掩盖了一个重要的事实，即“服务器”和“客户端”实际上表示了不同的网络行为；换句话说，是监听传入的连接还是建立到一个或者多个进程的连接。

面向连接的协议

请记住，严格来说，“连接”这个术语仅适用于面向连接的协议，如 TCP，其保证了两个连接端点之间消息的有序传递

传输

interface Channel

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CkRi9AdQ-1667891439095)(/img/netty/channel.png)]

每个 Channel 都将会被分配一个 ChannelPipeline 和 ChannelConfig。

ChannelConfig 包含了该 Channel 的所有配置设置，并且支持热更新。由于特定的传输可能具有独特的设置，所以它可能会实现一个 ChannelConfig 的子类型。（请参考 ChannelConfig实现对应的 Javadoc。）

由于 Channel 是独一无二的，所以为了保证顺序将 Channel 声明为 java.lang.Comparable 的一个子接口。因此，如果两个不同的 Channel 实例都返回了相同的散列码，那 么 AbstractChannel 中的 compareTo()方法的实现将会抛出一个 Error。

ChannelPipeline 持有所有将应用于入站和出站数据以及事件的 ChannelHandler 实例，这些 ChannelHandler 实现了应用程序用于处理状态变化以及数据处理的逻辑。

ChannelHandler 的典型用途包括：

• 将数据从一种格式转换为另一种格式
• 提供异常的通知
• 提供 Channel 变为活动的或者非活动的通知
• 提供当 Channel 注册到 EventLoop 或者从 EventLoop 注销时的通知
• 提供有关用户自定义事件的通知

你也可以根据需要通过添加或者移除ChannelHandler实例来修改ChannelPipeline。

Channel 方法

• eventLoop 返回分配给 Channel 的 EventLoop
• pipeline 返回分配给 Channel 的 ChannelPipeline
• isActive 如果 Channel 是活动的，则返回 true。活动的意义可能依赖于底层的传输。例如，一个 Socket 传输一旦连接到了远程节点便是活动的，而一个 Datagram 传输一旦被打开便是活动的
• localAddress 返回本地的 SokcetAddress
• remoteAddress 返回远程的 SocketAddress
• write 将数据写到远程节点。这个数据将被传递给 ChannelPipeline，并且排队直到它被冲刷
• flush 将之前已写的数据冲刷到底层传输，如一个 Socket
• writeAndFlush 一个简便的方法，等同于调用 write()并接着调用 flush()

NIO非阻塞 I/O

NIO 提供了一个所有 I/O 操作的全异步的实现。它利用了自 NIO 子系统被引入 JDK 1.4 时便可用的基于选择器的 API。

选择器背后的基本概念是充当一个注册表，在那里你将可以请求在 Channel 的状态发生变化时得到通知。可能的状态变化有：

• 新的 Channel 已被接受并且就绪；
• Channel 连接已经完成；
• Channel 有已经就绪的可供读取的数据；
• Channel 可用于写数据

选择器运行在一个检查状态变化并对其做出相应响应的线程上，在应用程序对状态的改变做出响应之后，选择器将会被重置，并将重复这个过程。

• OP_ACCEPT 请求在接受新连接并创建 Channel 时获得通知
• OP_CONNECT 请求在建立一个连接时获得通知
• OP_READ 请求当数据已经就绪，可以从 Channel 中读取时获得通知
• OP_WRITE 请求当可以向 Channel 中写更多的数据时获得通知。这处理了套接字缓冲区被完全填满时的情况，这种情况通常发生在数据的发送速度比远程节点可处理的速度更快的时候

ByteBuf

特点

Netty 的数据处理 API 通过两个组件暴露——abstract class ByteBuf 和 interface ByteBufHolder。

下面是一些 ByteBuf API 的优点：

• 它可以被用户自定义的缓冲区类型扩展；

• 通过内置的复合缓冲区类型实现了透明的零拷贝；

• 容量可以按需增长（类似于 JDK 的 StringBuilder）；

• 在读和写这两种模式之间切换不需要调用 ByteBuffer 的 flip()方法；

• 读和写使用了不同的索引；

• 支持方法的链式调用；

• 支持引用计数；

• 支持池化。

ByteBuf 的使用模式

堆缓冲区

最常用的 ByteBuf 模式是将数据存储在 JVM 的堆空间中。这种模式被称为支撑数组（backing array），它能在没有使用池化的情况下提供快速的分配和释放。这种方式。

ByteBuf heapBuf = ...;
    if (heapBuf.hasArray()) {
    byte[] array = heapBuf.array();
    int offset = heapBuf.arrayOffset() + heapBuf.readerIndex();
    int length = heapBuf.readableBytes();
    handleArray(array, offset, length);
}

:::tip 注意

当 hasArray()方法返回 false 时，尝试访问支撑数组将触发一个 Unsupported OperationException。这个模式类似于 JDK 的 ByteBuffer 的用法。

:::

直接缓冲区

直接缓冲区是另外一种 ByteBuf 模式。我们期望用于对象创建的内存分配永远都来自于堆中，但这并不是必须的——NIO 在 JDK 1.4 中引入的 ByteBuffer 类允许 JVM 实现通过本地调用来分配内存。这主要是为了避免在每次调用本地 I/O 操作之前（或者之后）将缓冲区的内容复制到一个中间缓冲区（或者从中间缓冲区把内容复制到缓冲区）。

ByteBuffer的Javadoc①明确指出：“直接缓冲区的内容将驻留在常规的会被垃圾回收的堆之外。”这也就解释了为何直接缓冲区对于网络数据传输是理想的选择。如果你的数据包含在一个在堆上分配的缓冲区中，那么事实上，在通过套接字发送它之前，JVM将会在内部把你的缓冲区复制到一个直接缓冲区中。

直接缓冲区的主要缺点是，相对于基于堆的缓冲区，它们的分配和释放都较为昂贵。如果你正在处理遗留代码，你也可能会遇到另外一个缺点：因为数据不是在堆上，所以你不得不进行一次复制。

显然，与使用支撑数组相比，这涉及的工作更多。因此，如果事先知道容器中的数据将会被作为数组来访问，你可能更愿意使用堆内存。

ByteBuf directBuf = ...;
if (!directBuf.hasArray()) {
    int length = directBuf.readableBytes();
    byte[] array = new byte[length];
    directBuf.getBytes(directBuf.readerIndex(), array);
    handleArray(array, 0, length);
}

复合缓冲区

第三种也是最后一种模式使用的是复合缓冲区，它为多个 ByteBuf 提供一个聚合视图。在这里你可以根据需要添加或者删除 ByteBuf 实例，这是一个 JDK 的 ByteBuffer 实现完全缺失的特性。

Netty 通过一个 ByteBuf 子类——CompositeByteBuf——实现了这个模式，它提供了一个将多个缓冲区表示为单个合并缓冲区的虚拟表示。

:::warning 警告

CompositeByteBuf 中的 ByteBuf 实例可能同时包含直接内存分配和非直接内存分配。如果其中只有一个实例，那么对 CompositeByteBuf 上的 hasArray()方法的调用将返回该组件上的 hasArray()方法的值；否则它将返回 false。

:::

使用 ByteBuffer 的复合缓冲区模式

ByteBuffer[] message = new ByteBuffer[] { header, body };
// Create a new ByteBuffer and use copy to merge the header and body
ByteBuffer message2 =
ByteBuffer.allocate(header.remaining() + body.remaining());
message2.put(header);
message2.put(body);
message2.flip();

使用 CompositeByteBuf 的复合缓冲区模式

CompositeByteBuf messageBuf = Unpooled.compositeBuffer();
ByteBuf headerBuf = ...; // can be backing or direct
ByteBuf bodyBuf = ...; // can be backing or direct
messageBuf.addComponents(headerBuf, bodyBuf);
messageBuf.removeComponent(0); // remove the header
for (ByteBuf buf : messageBuf) {
    System.out.println(buf.toString());
}

访问 CompositeByteBuf 中的数据

CompositeByteBuf compBuf = Unpooled.compositeBuffer();
int length = compBuf.readableBytes();
byte[] array = new byte[length];
compBuf.getBytes(compBuf.readerIndex(), array);
handleArray(array, 0, array.length);

需要注意的是，Netty使用了CompositeByteBuf来优化套接字的I/O操作，尽可能地消除了由JDK的缓冲区实现所导致的性能以及内存使用率的惩罚。

随机访问索引

如同在普通的 Java 字节数组中一样，ByteBuf 的索引是从零开始的：第一个字节的索引是0，最后一个字节的索引总是 capacity() - 1。

ByteBuf buffer = ...;
for (int i = 0; i < buffer.capacity(); i++) {
byte b = buffer.getByte(i);
	System.out.println((char)b);
}

需要注意的是，使用那些需要一个索引值参数的方法（的其中）之一来访问数据既不会改变readerIndex 也不会改变 writerIndex。如果有需要，也可以通过调用 readerIndex(index)或者 writerIndex(index)来手动移动这两者。

顺序访问索引

虽然 ByteBuf 同时具有读索引和写索引，但是 JDK 的 ByteBuffer 却只有一个索引，这也就是为什么必须调用 flip()方法来在读模式和写模式之间进行切换的原因。下图展示了ByteBuf 是如何被它的两个索引划分成 3 个区域的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MoTGSJQX-1667891439096)(/img/netty/bytebuf.png)]

可丢弃字节

通过调用 discardReadBytes()方法，可以丢弃它们并回收空间。这个分段的初始大小为 0，存储在 readerIndex 中，会随着 read 操作的执行而增加（get*操作不会移动 readerIndex）。

下图中所展示的缓冲区上调用discardReadBytes()方法后的结果。可以看到，可丢弃字节分段中的空间已经变为可写的了。注意，在调用discardReadBytes()之后，对可写分段的内容并没有任何的保证。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-noP3oxjt-1667891439097)(/img/netty/bytebuf-gc.png)]

可读字节

ByteBuf 的可读字节分段存储了实际数据。新分配的、包装的或者复制的缓冲区的默认的readerIndex 值为 0。任何名称以 read 或者 skip 开头的操作都将检索或者跳过位于当前readerIndex 的数据，并且将它增加已读字节数。

如果被调用的方法需要一个 ByteBuf 参数作为写入的目标，并且没有指定目标索引参数，那么该目标缓冲区的 writerIndex 也将被增加，例如：

readBytes(ByteBuf dest);

如果尝试在缓冲区的可读字节数已经耗尽时从中读取数据，那么将会引发一个 IndexOutOfBoundsException;

ByteBuf buffer = ...;
while (buffer.isReadable()) {
	System.out.println(buffer.readByte());
}

可写字节

可写字节分段是指一个拥有未定义内容的、写入就绪的内存区域。新分配的缓冲区的writerIndex 的默认值为 0。任何名称以 write 开头的操作都将从当前的 writerIndex 处开始写数据，并将它增加已经写入的字节数。如果写操作的目标也是 ByteBuf，并且没有指定源索引的值，则源缓冲区的 readerIndex 也同样会被增加相同的大小。这个调用如下所示：

writeBytes(ByteBuf dest);

如果尝试往目标写入超过目标容量的数据，将会引发一个IndexOutOfBoundException

ByteBuf buffer = ...;
while (buffer.writableBytes() >= 4) {
    buffer.writeInt(random.nextInt());
}

上述代码是一个用随机整数值填充缓冲区，直到它空间不足为止的例子。writeableBytes()方法在这里被用来确定该缓冲区中是否还有足够的空间。

索引管理

JDK 的 InputStream 定义了 mark(int readlimit)和 reset()方法，这些方法分别被用来将流中的当前位置标记为指定的值，以及将流重置到该位置。

同样，可以通过调用 markReaderIndex()、markWriterIndex()、resetWriterIndex()和 resetReaderIndex()来标记和重置 ByteBuf 的 readerIndex 和 writerIndex。这些和InputStream 上的调用类似，只是没有 readlimit 参数来指定标记什么时候失效。

也可以通过调用 readerIndex(int)或者 writerIndex(int)来将索引移动到指定位置。试 图将任何一个索引设置到一个无效的位置都将导致一个 IndexOutOfBoundsException。

可以通过调用 clear()方法来将 readerIndex 和 writerIndex 都设置为 0。注意，这并不会清除内存中的内容。图 5-5（重复上面的图 5-3）展示了它是如何工作的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vza5Hgyj-1667891439097)(/img/netty/bytebuf-index.png)]

调用 clear()比调用 discardReadBytes()轻量得多，因为它将只是重置索引而不会复制任何的内存。

查找操作

在ByteBuf中有多种可以用来确定指定值的索引的方法。最简单的是使用indexOf()方法。较复杂的查找可以通过那些需要一个ByteBufProcessor

ByteBufProcessor针对一些常见的值定义了许多便利的方法。假设你的应用程序需要和所谓的包含有以NULL结尾的内容的Flash套接字

作为参数的方法达成。这个接口只定义了一个方法：

boolean process(byte value)

它将检查输入值是否是正在查找的值。

ByteBufProcessor针对一些常见的值定义了许多便利的方法。假设你的应用程序需要和所谓的包含有以NULL结尾的内容的Flash套接字集成；

调用forEachByte(ByteBufProcessor.FIND_NUL)将简单高效地消费该 Flash 数据，因为在处理期间只会执行较少的边界检查。

ByteBuf buffer = ...;
int index = buffer.forEachByte(ByteBufProcessor.FIND_CR);

派生缓冲区

派生缓冲区为 ByteBuf 提供了以专门的方式来呈现其内容的视图。这类视图是通过以下方法被创建的：

• duplicate()；
• slice()；
• slice(int, int)；
• Unpooled.unmodifiableBuffer(…)；
• order(ByteOrder)；
• readSlice(int)。

每个这些方法都将返回一个新的 ByteBuf 实例，它具有自己的读索引、写索引和标记索引。其内部存储和 JDK 的 ByteBuffer 一样也是共享的。这使得派生缓冲区的创建成本是很低廉的，但是这也意味着，如果你修改了它的内容，也同时修改了其对应的源实例，所以要小心。

:::tip ByteBuf复制

如果需要一个现有缓冲区的真实副本，请使用 copy()或者 copy(int, int)方法。不同于派生缓冲区，由这个调用所返回的 ByteBuf 拥有独立的数据副本。

:::

Charset utf8 = Charset.forName("UTF-8");
ByteBuf buf = Unpooled.copiedBuffer("Netty in Action rocks!", utf8);
ByteBuf sliced = buf.slice(0, 15);
System.out.println(sliced.toString(utf8));
buf.setByte(0, (byte)'J');
assert buf.getByte(0) == sliced.getByte(0);

Charset utf8 = Charset.forName("UTF-8");
ByteBuf buf = Unpooled.copiedBuffer("Netty in Action rocks!", utf8);
ByteBuf copy = buf.copy(0, 15);
System.out.println(copy.toString(utf8));
buf.setByte(0, (byte) 'J');
assert buf.getByte(0) != copy.getByte(0);

读/写操作

正如我们所提到过的，有两种类别的读/写操作：

• get()和 set()操作，从给定的索引开始，并且保持索引不变；
• read()和 write()操作，从给定的索引开始，并且会根据已经访问过的字节数对索 引进行调整。

下面列举了最常用的 get()方法。完整列表请参考对应的 API 文档。

get操作

• getBoolean(int) 返回给定索引处的 Boolean 值
• getByte(int) 返回给定索引处的字节
• getUnsignedByte(int) 将给定索引处的无符号字节值作为 short 返回
• getMedium(int) 返回给定索引处的 24 位的中等 int 值
• getUnsignedMedium(int) 返回给定索引处的无符号的 24 位的中等 int 值
• getInt(int) 返回给定索引处的 int 值
• getUnsignedInt(int) 将给定索引处的无符号 int 值作为 long 返回
• getLong(int) 返回给定索引处的 long 值
• getShort(int) 返回给定索引处的 short 值
• getUnsignedShort(int) 将给定索引处的无符号 short 值作为 int 返回
• getBytes(int, …) 将该缓冲区中从给定索引开始的数据传送到指定的目的地

set操作

• setBoolean(int, boolean) 设定给定索引处的 Boolean 值
• setByte(int index, int value) 设定给定索引处的字节值
• setMedium(int index, int value) 设定给定索引处的 24 位的中等 int 值
• setInt(int index, int value) 设定给定索引处的 int 值
• setLong(int index, long value) 设定给定索引处的 long 值
• setShort(int index, int value) 设定给定索引处的 short 值

Charset utf8 = Charset.forName("UTF-8");
ByteBuf buf = Unpooled.copiedBuffer("Netty in Action rocks!", utf8);
System.out.println((char)buf.getByte(0));
int readerIndex = buf.readerIndex();
int writerIndex = buf.writerIndex();
buf.setByte(0, (byte)'B');
System.out.println((char)buf.getByte(0));
assert readerIndex == buf.readerIndex();
assert writerIndex == buf.writerIndex();

read()操作

其作用于当前的 readerIndex 或 writerIndex。这些方法将用于从 ByteBuf 中读取数据，如同它是一个流。

• readBoolean() 返回当前 readerIndex 处的 Boolean，并将 readerIndex 增加 1
• readByte() 返回当前 readerIndex 处的字节，并将 readerIndex 增加 1
• readUnsignedByte() 将当前 readerIndex 处的无符号字节值作为 short 返回，并将readerIndex 增加 1
• readMedium() 返回当前 readerIndex 处的 24 位的中等 int 值，并将 readerIndex增加 3
• readUnsignedMedium() 返回当前 readerIndex 处的 24 位的无符号的中等 int 值，并将readerIndex 增加 3
• readInt() 返回当前 readerIndex 的 int 值，并将 readerIndex 增加 4
• readUnsignedInt() 将当前 readerIndex 处的无符号的 int 值作为 long 值返回，并将readerIndex 增加 4
• readLong() 返回当前 readerIndex 处的 long 值，并将 readerIndex 增加 8
• readShort() 返回当前 readerIndex 处的 short 值，并将 readerIndex 增加 2
• readUnsignedShort() 将当前 readerIndex 处的无符号 short 值作为 int 值返回，并将readerIndex 增加 2
• readBytes(ByteBuf | byte[] destination,int dstIndex [,int length])将当前 ByteBuf 中从当前 readerIndex 处开始的（如果设置了，length 长度的字节）数据传送到一个目标 ByteBuf 或者 byte[]，从目标的 dstIndex 开始的位置。本地的 readerIndex 将被增加已经传输的字节数

write操作

• writeBoolean(boolean) 在当前 writerIndex 处写入一个 Boolean，并将 writerIndex 增加 1
• writeByte(int) 在当前 writerIndex 处写入一个字节值，并将 writerIndex 增加 1
• writeMedium(int) 在当前 writerIndex 处写入一个中等的 int 值，并将 writerIndex增加 3
• writeInt(int) 在当前 writerIndex 处写入一个 int 值，并将 writerIndex 增加 4
• writeLong(long) 在当前 writerIndex 处写入一个 long 值，并将 writerIndex 增加 8
• writeShort(int) 在当前 writerIndex 处写入一个 short 值，并将 writerIndex 增加 2
• writeBytes(source ByteBuf |byte[] [,int srcIndex,int length])从当前 writerIndex 开始，传输来自于指定源（ByteBuf 或者 byte[]）的数据。如果提供了 srcIndex 和 length，则从 srcIndex 开始读取，并且处理长度为 length 的字节。当前 writerIndex 将会被增加所写入的字节数

Charset utf8 = Charset.forName("UTF-8");
ByteBuf buf = Unpooled.copiedBuffer("Netty in Action rocks!", utf8);
System.out.println((char)buf.readByte());
int readerIndex = buf.readerIndex();
int writerIndex = buf.writerIndex();
buf.writeByte((byte)'?');
assert readerIndex == buf.readerIndex();
assert writerIndex != buf.writerIndex();

更多的操作

• isReadable() 如果至少有一个字节可供读取，则返回 true
• isWritable() 如果至少有一个字节可被写入，则返回 true
• readableBytes() 返回可被读取的字节数
• writableBytes() 返回可被写入的字节数
• capacity() 返回 ByteBuf 可容纳的字节数。在此之后，它会尝试再次扩展直到达到 maxCapacity()
• maxCapacity() 返回 ByteBuf 可以容纳的最大字节数
• hasArray() 如果 ByteBuf 由一个字节数组支撑，则返回 true
• array() 如果 ByteBuf 由一个字节数组支撑则返回该数组；否则，它将抛出一个UnsupportedOperationException 异常

ByteBufHolder 接口

除了实际的数据负载之外，我们还需要存储各种属性值。HTTP 响应便是一个很好的例子，除了表示为字节的内容，还包括状态码、cookie 等。

为了处理这种常见的用例，Netty 提供了 ByteBufHolder。ByteBufHolder 也为 Netty 的高级特性提供了支持，如缓冲区池化，其中可以从池中借用 ByteBuf，并且在需要时自动释放。

ByteBufHolder 只有几种用于访问底层数据和引用计数的方法。下表列出了它们（这里不包括它继承自 ReferenceCounted 的那些方法）。

• content() 返回由这个 ByteBufHolder 所持有的 ByteBuf
• copy() 返回这个 ByteBufHolder 的一个深拷贝，包括一个其所包含的 ByteBuf 的非共享拷贝
• duplicate() 返回这个 ByteBufHolder 的一个浅拷贝，包括一个其所包含的 ByteBuf 的共享拷贝

ByteBuf 分配

按需分配：ByteBufAllocator 接口

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2R1iZIaY-1667891439097)(/img/netty/bytebuf-allocator.png)]

可以通过 Channel（每个都可以有一个不同的 ByteBufAllocator 实例）或者绑定到ChannelHandler 的 ChannelHandlerContext 获取一个到 ByteBufAllocator 的引用。

Channel channel = ...;
ByteBufAllocator allocator = channel.alloc();
....
ChannelHandlerContext ctx = ...;
ByteBufAllocator allocator2 = ctx.alloc();

Netty提供了两种ByteBufAllocator的实现：PooledByteBufAllocator和UnpooledByteBufAllocator。前者池化了ByteBuf的实例以提高性能并最大限度地减少内存碎片。此实现使用了一种称为jemalloc的已被大量现代操作系统所采用的高效方法来分配内存。后者的实现不池化ByteBuf实例，并且在每次它被调用时都会返回一个新的实例。

虽然Netty默认 使用了PooledByteBufAllocator，但这可以很容易地通过ChannelConfig API或者在引导你的应用程序时指定一个不同的分配器来更改。

Unpooled 缓冲区

可能某些情况下，你未能获取一个到 ByteBufAllocator 的引用。对于这种情况，Netty 提供了一个简单的称为 Unpooled 的工具类，它提供了静态的辅助方法来创建未池化的 ByteBuf实例。下表列举了这些中最重要的方法。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BUFpy5Pt-1667891439098)(/img/netty/bytebuf-unpolled.png)]

ByteBufUtil 类

ByteBufUtil 提供了用于操作 ByteBuf 的静态的辅助方法。因为这个 API 是通用的，并且和池化无关，所以这些方法已然在分配类的外部实现。

这些静态方法中最有价值的可能就是 hexdump()方法，它以十六进制的表示形式打印ByteBuf 的内容。这在各种情况下都很有用，例如，出于调试的目的记录 ByteBuf 的内容。十六进制的表示通常会提供一个比字节值的直接表示形式更加有用的日志条目，此外，十六进制的版本还可以很容易地转换回实际的字节表示。

另一个有用的方法是 boolean equals(ByteBuf, ByteBuf)，它被用来判断两个 ByteBuf实例的相等性。如果你实现自己的 ByteBuf 子类，你可能会发现 ByteBufUtil 的其他有用方法。

引用计数

引用计数是一种通过在某个对象所持有的资源不再被其他对象引用时释放该对象所持有的资源来优化内存使用和性能的技术。Netty 在第 4 版中为 ByteBuf 和 ByteBufHolder 引入了引用计数技术，它们都实现了 interface ReferenceCounted。

引用计数背后的想法并不是特别的复杂；它主要涉及跟踪到某个特定对象的活动引用的数量。一个 ReferenceCounted 实现的实例将通常以活动的引用计数为 1 作为开始。只要引用计数大于 0，就能保证对象不会被释放。当活动引用的数量减少到 0 时，该实例就会被释放。注意，虽然释放的确切语义可能是特定于实现的，但是至少已经释放的对象应该不可再用了。

引用计数对于池化实现（如 PooledByteBufAllocator）来说是至关重要的，它降低了内存分配的开销。下面代码展示了相关的示例。

Channel channel = ...;
ByteBufAllocator allocator = channel.alloc();
....
ByteBuf buffer = allocator.directBuffer();
assert buffer.refCnt() == 1;

ByteBuf buffer = ...;
boolean released = buffer.release();

试图访问一个已经被释放的引用计数的对象，将会导致一个 IllegalReferenceCountException。

注意，一个特定的（ReferenceCounted 的实现）类，可以用它自己的独特方式来定义它的引用计数规则。例如，我们可以设想一个类，其 release()方法的实现总是将引用计数设为零，而不用关心它的当前值，从而一次性地使所有的活动引用都失效。

:::warning 谁负责释放

一般来说，是由最后访问（引用计数）对象的那一方来负责将它释放。

:::

Channel 和 Pipeline

Channel 的生命周期

Interface Channel 定义了一组和 ChannelInboundHandler API 密切相关的简单但功能强大的状态模型，下表列出了 Channel 的这 4 个状态。

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

Channel 的状态模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hRMhh59I-1667891439098)(/img/netty/channel-life.png)]

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

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

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

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

ChannelInboundHandler 接口

ChannelInboundHandler 的方法

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

:::warning 警告

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

:::

@Sharable
public class DiscardHandler extends ChannelInboundHandlerAdapter {
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) {
        ReferenceCountUtil.release(msg);
    }
}

继承SimpleChannelInboundHandler的Handler可以自动释放资源

public class SimpleDiscardHandler extends SimpleChannelInboundHandler<Object> {
    @Override
    public void channelRead0(ChannelHandlerContext ctx,
    Object msg) {
    // No need to do anything special
    } 
}

由于 SimpleChannelInboundHandler 会自动释放资源，所以你不应该存储指向任何消息的引用供将来使用，因为这些引用都将会失效。

ChannelOutboundHandler 接口

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,ChannelPromise)当请求通过 Channel 将数据写到远程节点时被调用

ChannelPromise与ChannelFuture ChannelOutboundHandler中的大部分方法都需要一个ChannelPromise参数，以便在操作完成时得到通知。ChannelPromise是ChannelFuture的一个子类，其定义了一些可写的方法，如setSuccess()和setFailure()，从而使ChannelFuture不可变。

ChannelHandler 适配器

你可以使用 ChannelInboundHandlerAdapter 和 ChannelOutboundHandlerAdapter类作为自己的 ChannelHandler 的起始点。这两个适配器分别提供了 ChannelInboundHandler和 ChannelOutboundHandler 的基本实现。通过扩展抽象类 ChannelHandlerAdapter，它们获得了它们共同的超接口 ChannelHandler 的方法。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8egB1goo-1667891439098)(/img/netty/channel-adapter.png)]

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

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

你要想在自己的 ChannelHandler 中使用这些适配器类，只需要简单地扩展它们，并且重写那些你想要自定义的方法。

释放资源

ReferenceCountUtil.release(msg);

ChannelPipeline 接口

如果你认为ChannelPipeline是一个拦截流经Channel的入站和出站事件的ChannelHandler 实例链，那么就很容易看出这些 ChannelHandler 之间的交互是如何组成一个应用程序数据和事件处理逻辑的核心的。

每一个新创建的 Channel 都将会被分配一个新的 ChannelPipeline。这项关联是永久性的；Channel 既不能附加另外一个 ChannelPipeline，也不能分离其当前的。在 Netty 组件的生命周期中，这是一项固定的操作，不需要开发人员的任何干预。

根据事件的起源，事件将会被 ChannelInboundHandler 或者 ChannelOutboundHandler扩展了ChannelInboundandlerAdapter 通过调用 ReferenceCountUtil.release()方法释放资源

扩展了ChannelOutboundHandlerAdapter通过使用 ReferenceCountUtil.realse(…)方法释放资源通知 ChannelPromise数据已经被处理了

处理。随后，通过调用 ChannelHandlerContext 实现，它将被转发给同一超类型的下一个ChannelHandler。

:::tip ChannelHandlerContext

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

:::

下图展示了一个典型的同时具有入站和出站 ChannelHandler 的 ChannelPipeline 的布局，并且印证了我们之前的关于 ChannelPipeline 主要由一系列的 ChannelHandler 所组成的说法。ChannelPipeline 还提供了通过 ChannelPipeline 本身传播事件的方法。如果一个入站事件被触发，它将被从 ChannelPipeline 的头部开始一直被传播到 Channel Pipeline 的尾端。

在下图中，一个出站 I/O 事件将从 ChannelPipeline 的最右边开始，然后向左传播。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mabXmjUs-1667891439099)(/img/netty/channel-context.png)]

:::tip ChannelPipeline 相对论

从事件途经 ChannelPipeline 的角度来看，ChannelPipeline 的头部和尾端取决于该事件是入站的还是出站的。然而 Netty 总是将 ChannelPipeline 的入站口作为头部，而将出站口作为尾端。

当你完成了通过调用 ChannelPipeline.add*()方法将入站处理器（ChannelInboundHandler）和出站处理器（ ChannelOutboundHandler ）混合添加到 ChannelPipeline 之后，每一个ChannelHandler 从头部到尾端的顺序位置正如同我们方才所定义它们的一样。因此，如果上图中的处理器（ChannelHandler）从左到右进行编号，那么第一个被入站事件看到的 ChannelHandler 将是1，而第一个被出站事件看到的 ChannelHandler 将是 5。

:::

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

修改 ChannelPipeline

ChannelHandler 可以通过添加、删除或者替换其他的 ChannelHandler 来实时地修改ChannelPipeline 的布局。（它也可以将它自己从 ChannelPipeline 中移除。）这是 ChannelHandler 最重要的能力之一。

• AddFirstaddBefore addAfteraddLast 将一个ChannelHandler 添加到ChannelPipeline 中
• remove 将一个ChannelHandler 从ChannelPipeline 中移除
• replace 将 ChannelPipeline 中的一个 ChannelHandler 替换为另一个 ChannelHandler

ChannelPipeline pipeline = ..;
FirstHandler firstHandler = new FirstHandler();
pipeline.addLast("handler1", firstHandler);
pipeline.addFirst("handler2", new SecondHandler());
pipeline.addLast("handler3", new ThirdHandler());
...
pipeline.remove("handler3");
pipeline.remove(firstHandler);
pipeline.replace("handler2", "handler4", new ForthHandler());

:::tip ChannelHandler 的执行和阻塞

通常 ChannelPipeline 中的每一个 ChannelHandler 都是通过它的 EventLoop（I/O 线程）来处理传递给它的事件的。所以至关重要的是不要阻塞这个线程，因为这会对整体的 I/O 处理产生负面的影响。

但有时可能需要与那些使用阻塞 API 的遗留代码进行交互。对于这种情况，ChannelPipeline 有一些接受一个 EventExecutorGroup 的 add()方法。如果一个事件被传递给一个自定义的 EventExecutorGroup，它将被包含在这个 EventExecutorGroup 中的某个 EventExecutor 所处理，从而被从该Channel 本身的 EventLoop 中移除。对于这种用例，Netty 提供了一个叫 DefaultEventExecutorGroup 的默认实现。

:::

ChannelPipeline 的用于访问 ChannelHandler 的操作

• get 通过类型或者名称返回 ChannelHandler
• context 返回和 ChannelHandler 绑定的 ChannelHandlerContext
• names 返回 ChannelPipeline 中所有 ChannelHandler 的名称

触发事件

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

ChannelPipeline 的入站操作

• fireChannelRegistered 调用 ChannelPipeline 中下一个 ChannelInboundHandler 的channelRegistered(ChannelHandlerContext)方法
• fireChannelUnregistered 调用 ChannelPipeline 中下一个 ChannelInboundHandler 的channelUnregistered(ChannelHandlerContext)方法
• fireChannelActive 调用 ChannelPipeline 中下一个 ChannelInboundHandler 的channelActive(ChannelHandlerContext)方法
• fireChannelInactive 调用 ChannelPipeline 中下一个 ChannelInboundHandler 的channelInactive(ChannelHandlerContext)方法
• fireExceptionCaught 调用 ChannelPipeline 中下一个 ChannelInboundHandler 的exceptionCaught(ChannelHandlerContext, Throwable)方法
• fireUserEventTriggered 调用 ChannelPipeline 中下一个 ChannelInboundHandler 的userEventTriggered(ChannelHandlerContext, Object)方法
• fireChannelRead 调用 ChannelPipeline 中下一个 ChannelInboundHandler 的channelRead(ChannelHandlerContext, Object msg)方法fireChannelReadComplete 调用 ChannelPipeline 中下一个 ChannelInboundHandler 的channelReadComplete(ChannelHandlerContext)方法
• fireChannelWritabilityChanged调用 ChannelPipeline 中下一个 ChannelInboundHandler 的channelWritabilityChanged(ChannelHandlerContext)方法

ChannelPipeline 的出站操作

• bind 将 Channel 绑定到一个本地地址，这将调用 ChannelPipeline 中的下一个ChannelOutboundHandler 的 bind(ChannelHandlerContext, SocketAddress, ChannelPromise)方法
• connect 将 Channel 连接到一个远程地址，这将调用 ChannelPipeline 中的下一个ChannelOutboundHandler 的 connect(ChannelHandlerContext, SocketAddress, ChannelPromise)方法
• disconnect 将Channel 断开连接。这将调用ChannelPipeline 中的下一个ChannelOutboundHandler 的 disconnect(ChannelHandlerContext, Channel Promise)方法
• close 将 Channel 关闭。这将调用 ChannelPipeline 中的下一个 ChannelOutboundHandler 的 close(ChannelHandlerContext, ChannelPromise)方法
• deregister 将 Channel 从它先前所分配的 EventExecutor（即 EventLoop）中注销。这将调用 ChannelPipeline 中的下一个 ChannelOutboundHandler 的 deregister(ChannelHandlerContext, ChannelPromise)方法
• flush 冲刷Channel所有挂起的写入。这将调用ChannelPipeline中的下一个ChannelOutboundHandler 的 flush(ChannelHandlerContext)方法
• write 将消息写入 Channel。这将调用 ChannelPipeline 中的下一个 ChannelOutboundHandler的write(ChannelHandlerContext, Object msg, ChannelPromise)方法。注意：这并不会将消息写入底层的 Socket，而只会将它放入队列中。要将它写入 Socket，需要调用 flush()或者 writeAndFlush()方法
• writeAndFlush 这是一个先调用 write()方法再接着调用 flush()方法的便利方法
• read 请求从 Channel 中读取更多的数据。这将调用 ChannelPipeline 中的下一个ChannelOutboundHandler 的 read(ChannelHandlerContext)方法

总结

• ChannelPipelne 保存了与 Channel 相关联的 ChannelHandler；
• ChannelPipeline 可以根据需要，通过添加或者删除 ChannelHandler 来动态地修改；
• ChannelPipeline 有着丰富的 API 用以被调用，以响应入站和出站事件。

ChannelHandlerContext 接口

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

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

ChannelHandlerContext 的 API

• alloc 返回和这个实例相关联的Channel 所配置的 ByteBufAllocator

• bind 绑定到给定的 SocketAddress，并返回 ChannelFuture

• channel 返回绑定到这个实例的 Channel

• close 关闭 Channel，并返回 ChannelFuture

• connect 连接给定的 SocketAddress，并返回 ChannelFuture

• deregister 从之前分配的 EventExecutor 注销，并返回 ChannelFuture

• disconnect 从远程节点断开，并返回 ChannelFuture

• executor 返回调度事件的 EventExecutor

• fireChannelActive 触发对下一个 ChannelInboundHandler 上的channelActive()方法（已连接）的调用

• fireChannelInactive 触发对下一个 ChannelInboundHandler 上的channelInactive()方法（已关闭）的调用

• fireChannelRead 触发对下一个 ChannelInboundHandler 上的channelRead()方法（已接收的消息）的调用

• fireChannelReadComplete 触发对下一个ChannelInboundHandler上的channelReadComplete()方法的调用

• fireChannelRegistered 触发对下一个 ChannelInboundHandler 上的fireChannelRegistered()方法的调用

• fireChannelUnregistered 触发对下一个 ChannelInboundHandler 上的fireChannelUnregistered()方法的调用

• fireChannelWritabilityChanged 触发对下一个 ChannelInboundHandler 上的fireChannelWritabilityChanged()方法的调用

• fireExceptionCaught 触发对下一个 ChannelInboundHandler 上的fireExceptionCaught(Throwable)方法的调用

• fireUserEventTriggered 触发对下一个 ChannelInboundHandler 上的fireUserEventTriggered(Object evt)方法的调用

• handler 返回绑定到这个实例的 ChannelHandler

• isRemoved 如果所关联的 ChannelHandler 已经被从 ChannelPipeline中移除则返回 true

• name 返回这个实例的唯一名称

• pipeline 返回这个实例所关联的 ChannelPipeline

• read 将数据从Channel读取到第一个入站缓冲区；如果读取成功则触发 ①一个channelRead事件，并（在最后一个消息被读取完成后）通 知 ChannelInboundHandler 的 channelReadComplete(ChannelHandlerContext)方法

• write 通过这个实例写入消息并经过 ChannelPipeline

• writeAndFlush 通过这个实例写入并冲刷消息并经过 ChannelPipeline

:::tip 注意

当使用 ChannelHandlerContext 的 API 的时候，请牢记以下两点：

• ChannelHandlerContext 和 ChannelHandler 之间的关联（绑定）是永远不会改变的，所以缓存对它的引用是安全的；
• 如同我们在本节开头所解释的一样，相对于其他类的同名方法，ChannelHandler Context的方法将产生更短的事件流，应该尽可能地利用这个特性来获得最大的性能。

:::

使用 ChannelHandlerContext

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3Dv0Hl1a-1667891439099)(/img/netty/ChannelHandlerContext.png)]

ChannelHandlerContext ctx = ..;
Channel channel = ctx.channel();
channel.write(Unpooled.copiedBuffer("Netty in Action",CharsetUtil.UTF_8));

ChannelHandlerContext ctx = ..;
ChannelPipeline pipeline = ctx.pipeline();
pipeline.write(Unpooled.copiedBuffer("Netty in Action",CharsetUtil.UTF_8));

重要的是要注意到，虽然被调用的 Channel 或 ChannelPipeline 上的 write()方法将一直传播事件通过整个 ChannelPipeline，但是在 ChannelHandler 的级别上，事件从一个 ChannelHandler到下一个 ChannelHandler 的移动是由 ChannelHandlerContext 上的调用完成的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Nfcs8bqk-1667891439099)(/img/netty/channel-event.png)]

为什么会想要从 ChannelPipeline 中的某个特定点开始传播事件呢？

• 为了减少将事件传经对它不感兴趣的 ChannelHandler 所带来的开销。
• 为了避免将事件传经那些可能会对它感兴趣的 ChannelHandler。

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

ChannelHandlerContext ctx = ..;
ctx.write(Unpooled.copiedBuffer("Netty in Action", CharsetUtil.UTF_8));

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C3lfpuq8-1667891439100)(/img/netty/channel-context-event.png)]

消息将从下一个 ChannelHandler 开始流经 ChannelPipeline，绕过了所有前面的 ChannelHandler。

异常处理

处理入站异常

如果在处理入站事件的过程中有异常被抛出，那么它将从它在 ChannelInboundHandler里被触发的那一点开始流经 ChannelPipeline。要想处理这种类型的入站异常，你需要在你的 ChannelInboundHandler 实现中重写下面的方法。

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception

public class InboundExceptionHandler extends ChannelInboundHandlerAdapter {
	@Override
    public void exceptionCaught(ChannelHandlerContext ctx,Throwable cause) {
        cause.printStackTrace();
        ctx.close();
    }
}

因为异常将会继续按照入站方向流动（就像所有的入站事件一样），所以实现了前面所示逻辑的 ChannelInboundHandler 通常位于 ChannelPipeline 的最后。这确保了所有的入站异常都总是会被处理，无论它们可能会发生在 ChannelPipeline 中的什么位置。

你应该如何响应异常，可能很大程度上取决于你的应用程序。你可能想要关闭Channel（和连接），也可 能会尝试进行恢复。如果你不实现任何处理入站异常的逻辑（或者没有消费该异常），那么Netty将会记录该异常没有被处理的事实。

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

处理出站异常

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

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

ChannelPromise setSuccess();
ChannelPromise setFailure(Throwable cause);

添加 ChannelFutureListener 只需要调用 ChannelFuture 实例上的 addListener(ChannelFutureListener)方法，并且有两种不同的方式可以做到这一点。其中最常用的方式是，调用出站操作（如 write()方法）所返回的 ChannelFuture 上的 addListener()方法。

ChannelFuture future = channel.write(someMessage);

future.addListener(new ChannelFutureListener() {
    @Override
    public void operationComplete(ChannelFuture f) {
        if (!f.isSuccess()) {
            f.cause().printStackTrace();
            f.channel().close();
        } 
    }
});

第二种方式是将 ChannelFutureListener 添加到即将作为参数传递给 ChannelOutboundHandler 的方法的 ChannelPromise。

public class OutboundExceptionHandler extends ChannelOutboundHandlerAdapter {
    @Override
    public void write(ChannelHandlerContext ctx, Object msg,ChannelPromise promise) {
        promise.addListener(new ChannelFutureListener() {
            @Override
            public void operationComplete(ChannelFuture f) {
                if (!f.isSuccess()) {
                    f.cause().printStackTrace();
                    f.channel().close();
                    } }
                }
          );
      } 
}

:::tip ChannelPromise 的可写方法

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

:::

EventLoop 线程模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-btVYquOT-1667891439100)(/img/netty/execute.png)]

EventLoop 接口

运行任务来处理在连接的生命周期内发生的事件是任何网络框架的基本功能。与之相应的编程上的构造通常被称为事件循环—一个 Netty 使用了 interface io.netty.channel.EventLoop 来适配的术语。

Netty 的 EventLoop 是协同设计的一部分，它采用了两个基本的 API：并发和网络编程。首先，io.netty.util.concurrent 包构建在 JDK 的 java.util.concurrent 包上，用来提供线程执行器。其次，io.netty.channel 包中的类，为了与 Channel 的事件进行交互，扩展了这些接口/类。下图展示了生成的类层次结构。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9BUfF9gH-1667891439100)(/img/netty/event-group.png)]

在这个模型中，一个 EventLoop 将由一个永远都不会改变的 Thread 驱动，同时任务（Runnable 或者 Callable）可以直接提交给 EventLoop 实现，以立即执行或者调度执行。

根据配置和可用核心的不同，可能会创建多个 EventLoop 实例用以优化资源的使用，并且单个EventLoop 可能会被指派用于服务多个 Channel。

需要注意的是，Netty的EventLoop在继承了ScheduledExecutorService的同时，只定义了一个方法，parent()。这个方法，如下面的代码片断所示，用于返回到当前EventLoop实现的实例所属的EventLoopGroup的引用。

public interface EventLoop extends EventExecutor, EventLoopGroup {
    @Override
    EventLoopGroup parent();
}

:::warning 事件/任务的执行顺序

事件和任务是以先进先出（FIFO）的顺序执行的。这样可以通过保证字节内容总是按正确的顺序被处理，消除潜在的数据损坏的可能性。

:::

由 I/O 操作触发的事件将流经安装了一个或者多个ChannelHandler 的 ChannelPipeline。传播这些事件的方法调用可以随后被 ChannelHandler 所拦截，并且可以按需地处理事件。

事件的性质通常决定了它将被如何处理；它可能将数据从网络栈中传递到你的应用程序中，或者进行逆向操作，或者 执行一些截然不同的操作。但是事件的处理逻辑必须足够的通用和灵活，以处理所有可能的用例。因此，在Netty 4 中，所有的I/O操作和事件都由已经被分配给了EventLoop的那个Thread来处理。

使用 EventLoop 调度任务

ScheduledExecutorService 的实现具有局限性，例如，事实上作为线程池管理的一部分，将会有额外的线程创建。如果有大量任务被紧凑地调度，那么这将成为一个瓶颈。Netty 通 过 Channel 的 EventLoop 实现任务调度解决了这一问题。

Channel ch = ...
ScheduledFuture<?> future = ch.eventLoop().schedule(
new Runnable() {
    @Override
    public void run() {
   	 System.out.println("60 seconds later");
    }
}, 60, TimeUnit.SECONDS);

经过 60 秒之后，Runnable 实例将由分配给 Channel 的 EventLoop 执行。如果要调度任务以每隔 60 秒执行一次，请使用 scheduleAtFixedRate()方法。

ScheduledFuture<?> future = ch.eventLoop().scheduleAtFixedRate(
new Runnable() {
    @Override
    public void run() {
    	System.out.println("Run every 60 seconds");
    }
}, 60, 60, TimeUnit.Seconds);

用 ScheduledFuture 取消任务

ScheduledFuture<?> future = ch.eventLoop().scheduleAtFixedRate(...);
// Some other code that runs...
boolean mayInterruptIfRunning = false;
future.cancel(mayInterruptIfRunning);

线程管理

Netty线程模型的卓越性能取决于对于当前执行的Thread的身份的确定,也就是说，确定它是否是分配给当前Channel以及它的EventLoop的那一个线程。

如果（当前）调用线程正是支撑 EventLoop 的线程，那么所提交的代码块将会被（直接）执行。否则，EventLoop 将调度该任务以便稍后执行，并将它放入到内部队列中。当 EventLoop下次处理它的事件时，它会执行队列中的那些任务/事件。这也就解释了任何的 Thread 是如何与 Channel 直接交互而无需在 ChannelHandler 中进行额外同步的。

注意，每个 EventLoop 都有它自已的任务队列，独立于任何其他的 EventLoop。下图展示了 EventLoop 用于调度任务的执行逻辑。这是 Netty 线程模型的关键组成部分：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6NiJ6s3v-1667891439101)(/img/netty/thread-event.png)]

我们之前已经阐明了不要阻塞当前 I/O 线程的重要性。我们再以另一种方式重申一次：“永远不要将一个长时间运行的任务放入到执行队列中，因为它将阻塞需要在同一线程上执行的任何其他任务。”如果必须要进行阻塞调用或者执行长时间运行的任务，我们建议使用一个专门的EventExecutor。

引导

Bootstrap 类

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WFwaglV7-1667891439101)(/img/netty/bootstrap.png)]

相对于将具体的引导类分别看作用于服务器和客户端的引导来说，记住它们的本意是用来支撑不同的应用程序的功能的将有所裨益。也就是说，服务器致力于使用一个父 Channel 来接受来自客户端的连接，并创建子 Channel 以用于它们之间的通信；而客户端将最可能只需要一个单独的、没有父 Channel 的 Channel 来用于所有的网络交互。（正如同我们将要看到的，这也适用于无连接的传输协议，如 UDP，因为它们并不是每个连接都需要一个单独的 Channel。）

客户端和服务端两种应用程序类型之间通用的引导步骤由 AbstractBootstrap 处理，而特定于客户端或者服务器的引导步骤则分别由 Bootstrap 或 ServerBootstrap 处理。

AbstractBootstrap 类的完整声明是：

public abstract class AbstractBootstrap<B> extends AbstractBootstrap<B,C>,C extends Channel>

public class Bootstrap extends AbstractBootstrap<Bootstrap,Channel>

public class ServerBootstrap extends  AbstractBootstrap<ServerBootstrap,ServerChannel>

引导客户端和无连接协议

Bootstrap group(EventLoopGroup) 设置用于处理 Channel 所有事件的 EventLoopGroup

• Bootstrap channel(Class) Bootstrap channelFactory( ChannelFactory) channel()方法指定了Channel的实现类。如果该实现类没提供默认的构造函数 ① ，可以通过调用channelFactory()方法来指定一个工厂类，它将会被bind()方法调用

• Bootstrap localAddress(SocketAddress)指定 Channel 应该绑定到的本地地址。如果没有指定，则将由操作系统创建一个随机的地址。或者，也可以通过

• bind()或者 connect()方法指定 localAddress

• Bootstrap option(ChannelOption<\T> option,T value)设置 ChannelOption，其将被应用到每个新创建的Channel 的 ChannelConfig。这些选项将会通过

• bind()或者 connect()方法设置到 Channel，不管哪 个先被调用。这个方法在 Channel 已经被创建后再调用将不会有任何的效果。支持的 ChannelOption 取决于使用的 Channel 类型。

• Bootstrap attr(Attribute key, T value)指定新创建的 Channel 的属性值。这些属性值是通过bind()或者 connect()方法设置到 Channel 的，具体

• 取决于谁最先被调用。

• Bootstrap handler(ChannelHandler)设置将被添加到 ChannelPipeline 以接收事件通知的ChannelHandler

• Bootstrap clone() 创建一个当前 Bootstrap 的克隆，其具有和原始的Bootstrap 相同的设置信息

• Bootstrap remoteAddress(SocketAddress)设置远程地址。或者，也可以通过 connect()方法来指定它

• ChannelFuture connect() 连接到远程节点并返回一个 ChannelFuture，其将 会在连接操作完成后接收到通知

• ChannelFuture bind() 绑定 Channel 并返回一个 ChannelFuture，其将会在绑定操作完成后接收到通知，在那之后必须调用 Channel.connect()方法来建立连接

引导客户端

Bootstrap 类负责为客户端和使用无连接协议的应用程序创建 Channel

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Q9SFCom9-1667891439101)(/img/netty/bootstrap-init.png)]

EventLoopGroup group = new NioEventLoopGroup();
Bootstrap bootstrap = new Bootstrap();
bootstrap.group(group)
    .channel(NioSocketChannel.class)
    .handler(new SimpleChannelInboundHandler<ByteBuf>() {
        @Override
        protected void channelRead0(ChannelHandlerContext channelHandlerContext, ByteBuf byteBuf) throws Exception {
            System.out.println("Received data");
        }
    });

ChannelFuture future = bootstrap.connect(new InetSocketAddress("www.manning.com", 80));
future.addListener(new ChannelFutureListener() {
    @Override
    public void operationComplete(ChannelFuture channelFuture)
        throws Exception {
        if (channelFuture.isSuccess()) {
            System.out.println("Connection established");
        } else {
            System.err.println("Connection attempt failed");
            channelFuture.cause().printStackTrace();
        }
    }
});

Channel 和 EventLoopGroup 的兼容性

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1KmzN849-1667891439102)(/img/netty/channel-extend.png)]

不兼容的 Channel 和 EventLoopGroup

		EventLoopGroup group = new NioEventLoopGroup();
        Bootstrap bootstrap = new Bootstrap();
        bootstrap.group(group)
                .channel(OioSocketChannel.class)
                .handler(new SimpleChannelInboundHandler<ByteBuf>() {
                    @Override
                    protected void channelRead0(
                            ChannelHandlerContext channelHandlerContext,
                            ByteBuf byteBuf) throws Exception {
                        System.out.println("Received data");
                    }
                });
        ChannelFuture future = bootstrap.connect(
                new InetSocketAddress("www.manning.com", 80));
        future.syncUninterruptibly();

这段代码将会导致 IllegalStateException，因为它混用了不兼容的传输。

::: 关于 IllegalStateException 的更多讨论

在引导的过程中，在调用 bind()或者 connect()方法之前，必须调用以下方法来设置所需的组件：

• group()；
• channel()或者 channelFactory()；
• handler()。

如果不这样做，则将会导致 IllegalStateException。对 handler()方法的调用尤其重要，因为它需要配置好 ChannelPipeline。

:::

引导服务器

ServerBootstrap 类的方法

• group 设置 ServerBootstrap 要用的 EventLoopGroup。这个 EventLoopGroup将用于 ServerChannel 和被接受的子 Channel 的 I/O 处理
• channel 设置将要被实例化的 ServerChannel 类
• channelFactory 如果不能通过默认的构造函数 ①创建Channel，那么可以提供一个ChannelFactory
• localAddress 指定 ServerChannel 应该绑定到的本地地址。如果没有指定，则将由操作系统使用一个随机地址。或者，可以通过 bind()方法来指定该 localAddress
• option 指定要应用到新创建的 ServerChannel 的 ChannelConfig 的 ChannelOption。这些选项将会通过 bind()方法设置到 Channel。在 bind()方法
• 被调用之后，设置或者改变 ChannelOption 都不会有任何的效果。所支持的 ChannelOption 取决于所使用的 Channel 类型。
• childOption 指定当子 Channel 被接受时，应用到子 Channel 的 ChannelConfig 的ChannelOption。所支持的 ChannelOption 取决于所使用的 Channel 的类
• 型。
• attr 指定 ServerChannel 上的属性，属性将会通过 bind()方法设置给 Channel。在调用 bind()方法之后改变它们将不会有任何的效果
• childAttr 将属性设置给已经被接受的子 Channel。接下来的调用将不会有任何的效果
• handler 设置被添加到ServerChannel 的ChannelPipeline中的ChannelHandler。更加常用的方法参见 childHandler()
• childHandler 设置将被添加到已被接受的子 Channel 的 ChannelPipeline 中的 ChannelHandler。handler()方法和 childHandler()方法之间的区别是：前者所添加的 ChannelHandler 由接受子 Channel 的 ServerChannel 处理，而childHandler()方法所添加的 ChannelHandler 将由已被接受的子 Channel处理，其代表一个绑定到远程节点的套接字
• clone 克隆一个设置和原始的 ServerBootstrap 相同的 ServerBootstrap
• bind 绑定 ServerChannel 并且返回一个 ChannelFuture，其将会在绑定操作完成后收到通知（带着成功或者失败的结果

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Tm2uEr6a-1667891439102)(/img/netty/serverBootstrap.png)]

  NioEventLoopGroup group = new NioEventLoopGroup();
        ServerBootstrap bootstrap = new ServerBootstrap();
        bootstrap.group(group)
                .channel(NioServerSocketChannel.class)
                .childHandler(new SimpleChannelInboundHandler<ByteBuf>() {
                    @Override
                    protected void channelRead0(ChannelHandlerContext ctx,
                                                ByteBuf byteBuf) throws Exception {
                        System.out.println("Received data");
                    }
                });
        ChannelFuture future = bootstrap.bind(new InetSocketAddress(8080));
        future.addListener(new ChannelFutureListener() {
            @Override
            public void operationComplete(ChannelFuture channelFuture)
                    throws Exception {
                if (channelFuture.isSuccess()) {
                    System.out.println("Server bound");
                } else {
                    System.err.println("Bound attempt failed");
                    channelFuture.cause().printStackTrace();
                }
            }
        });

引导客户端

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-g4TVsTUM-1667891439102)(/img/netty/clientBootstrap.png)]

   ServerBootstrap bootstrap = new ServerBootstrap();
        bootstrap
                .group(new NioEventLoopGroup(), new NioEventLoopGroup())
                .channel(NioServerSocketChannel.class)
                .childHandler(
                        new SimpleChannelInboundHandler<ByteBuf>() {
                            ChannelFuture connectFuture;

                            @Override
                            public void channelActive(ChannelHandlerContext ctx)
                                    throws Exception {
                                Bootstrap bootstrap = new Bootstrap();
                                bootstrap.channel(NioSocketChannel.class).handler(
                                        new SimpleChannelInboundHandler<ByteBuf>() {
                                            @Override
                                            protected void channelRead0(
                                                    ChannelHandlerContext ctx, ByteBuf in)
                                                    throws Exception {
                                                System.out.println("Received data");
                                            }
                                        });
                                bootstrap.group(ctx.channel().eventLoop());
                                connectFuture = bootstrap.connect(
                                        new InetSocketAddress("www.manning.com", 80));
                            }

                            @Override
                            protected void channelRead0(
                                    ChannelHandlerContext channelHandlerContext,
                                    ByteBuf byteBuf) throws Exception {
                                if (connectFuture.isDone()) {
                                    // do something with the data
                                }
                            }
                        });
        ChannelFuture future = bootstrap.bind(new InetSocketAddress(8080));
        future.addListener(new ChannelFutureListener() {
            @Override
            public void operationComplete(ChannelFuture channelFuture)
                    throws Exception {
                if (channelFuture.isSuccess()) {
                    System.out.println("Server bound");
                } else {
                    System.err.println("Bind attempt failed");
                    channelFuture.cause().printStackTrace();
                }
            }
        });

引导 DatagramChannel

        Bootstrap bootstrap = new Bootstrap();
        bootstrap.group(new OioEventLoopGroup()).channel(
                OioDatagramChannel.class).handler(
                new SimpleChannelInboundHandler<DatagramPacket>() {
                    @Override
                    public void channelRead0(ChannelHandlerContext ctx,
                                             DatagramPacket msg) throws Exception {
                                // Do something with the packet
                    }
                }
        );
        ChannelFuture future = bootstrap.bind(new InetSocketAddress(0));
        future.addListener(new ChannelFutureListener() {
            @Override
            public void operationComplete(ChannelFuture channelFuture)
                    throws Exception {
                if (channelFuture.isSuccess()) {
                    System.out.println("Channel bound");
                } else {
                    System.err.println("Bind attempt failed");
                    channelFuture.cause().printStackTrace();
                }
            }
        });

关闭

引导使你的应用程序启动并且运行起来，但是迟早你都需要优雅地将它关闭。当然，你也可以让 JVM 在退出时处理好一切，但是这不符合优雅的定义，优雅是指干净地释放资源。关闭 Netty应用程序并没有太多的魔法，但是还是有些事情需要记在心上。

最重要的是，你需要关闭 EventLoopGroup，它将处理任何挂起的事件和任务，并且随后释放所有活动的线程。这就是调用 EventLoopGroup.shutdownGracefully()方法的作用。

这个方法调用将会返回一个 Future，这个 Future 将在关闭完成时接收到通知。需要注意的是，shutdownGracefully()方法也是一个异步的操作，所以你需要阻塞等待直到它完成，或者向所返回的 Future 注册一个监听器以在关闭完成时获得通知。

EventLoopGroup group = new NioEventLoopGroup();
Bootstrap bootstrap = new Bootstrap();
bootstrap.group(group)
.channel(NioSocketChannel.class);
...
Future<?> future = group.shutdownGracefully();
// block until the group has shutdown
future.syncUninterruptibly();

或者，你也可以在调用 EventLoopGroup.shutdownGracefully()方法之前，显式地在所有活动的 Channel 上调用 Channel.close()方法。但是在任何情况下，都请记得关闭EventLoopGroup 本身。

编解码器

每个网络应用程序都必须定义如何解析在两个节点之间来回传输的原始字节，以及如何将其和目标应用程序的数据格式做相互转换。这种转换逻辑由编解码器处理，编解码器由编码器和解码器组成，它们每种都可以将字节流从一种格式转换为另一种格式。

如果将消息看作是对于特定的应用程序具有具体含义的结构化的字节序列—它的数据。那么编码器是将消息转换为适合于传输的格式（最有可能的就是字节流）；而对应的解码器则是将网络字节流转换回应用程序的消息格式。因此，编码器操作出站数据，而解码器处理入站数据。

解码器

• 将字节解码为消息——ByteToMessageDecoder 和 ReplayingDecoder；
• 将一种消息类型解码为另一种——MessageToMessageDecoder。

因为解码器是负责将入站数据从一种格式转换到另一种格式的，所以知道 Netty 的解码器实现了 ChannelInboundHandler 也不会让你感到意外。

什么时候会用到解码器呢？很简单：每当需要为 ChannelPipeline 中的下一个 ChannelInboundHandler 转换入站数据时会用到。此外，得益于 ChannelPipeline 的设计，可以将多个解码器链接在一起，以实现任意复杂的转换逻辑，这也是 Netty 是如何支持代码的模块化以及复用的一个很好的例子。

抽象类 ByteToMessageDecoder

将字节解码为消息（或者另一个字节序列）是一项如此常见的任务，以至于 Netty 为它提供了一个抽象的基类：ByteToMessageDecoder。由于你不可能知道远程节点是否会一次性地发送一个完整的消息，所以这个类会对入站数据进行缓冲，直到它准备好处理。

ByteToMessageDecoder API

decode(ChannelHandlerContext ctx,ByteBuf in,List