Netty 源码深度解析(九) - 编码

绝地灬酷狼 2022-02-12 20:36 201阅读 0赞

# 概述 #

## 一个问题 ##

![1240][]  
![1240 1][]  
编码器实现了`ChannelOutboundHandler`，并将出站数据从 一种格式转换为另一种格式，和我们方才学习的解码器的功能正好相反。Netty 提供了一组类， 用于帮助你编写具有以下功能的编码器:

*  将消息编码为字节
 *  将消息编码为消息  
    我们将首先从抽象基类 MessageToByteEncoder 开始来对这些类进行考察

# 1 抽象类 MessageToByteEncoder #

![MessageToByteEncoder API][]  
解码器通常需要在`Channel`关闭之后产生最后一个消息(因此也就有了 `decodeLast()`方法)  
这显然不适于编码器的场景——在连接被关闭之后仍然产生一个消息是毫无意义的

## 1.1 ShortToByteEncoder ##

其接受一`Short` 型实例作为消息，编码为`Short`的原子类型值，并写入`ByteBuf`，随后转发给`ChannelPipeline`中的下一个 `ChannelOutboundHandler`  
每个传出的 Short 值都将会占用 ByteBuf 中的 2 字节  
![ShortToByteEncoder][]  
![1240 2][]

## 1.2 Encoder ##

![1240 3][]

Netty 提供了一些专门化的 `MessageToByteEncoder`，可基于此实现自己的编码器  
`WebSocket08FrameEncoder`类提供了一个很好的实例  
![1240 4][]

# 2 抽象类 MessageToMessageEncoder #

你已经看到了如何将入站数据从一种消息格式解码为另一种  
为了完善这幅图，将展示 对于出站数据将如何从一种消息编码为另一种。`MessageToMessageEncoder`类的 `encode()`方法提供了这种能力  
![MessageToMessageEncoderAPI][]  
为了演示,使用`IntegerToStringEncoder` 扩展了 `MessageToMessageEncoder`

*  编码器将每个出站 Integer 的 String 表示添加到了该 List 中  
    ![1240 5][]

![IntegerToStringEncoder的设计][IntegerToStringEncoder]

关于有趣的 MessageToMessageEncoder 的专业用法，请查看 `io.netty.handler. codec.protobuf.ProtobufEncoder`类，它处理了由 Google 的 Protocol Buffers 规范所定义 的数据格式。

# 一个java对象最后是如何转变成字节流，写到socket缓冲区中去的 #

![1240 6][]

pipeline中的标准链表结构  
java对象编码过程  
write：写队列  
flush：刷新写队列  
writeAndFlush: 写队列并刷新

## pipeline中的标准链表结构 ##

![标准的pipeline链式结构][pipeline]  
数据从head节点流入，先拆包，然后解码成业务对象，最后经过业务`Handler`处理，调用`write`，将结果对象写出去  
而写的过程先通过`tail`节点，然后通过`encoder`节点将对象编码成`ByteBuf`，最后将该`ByteBuf`对象传递到`head`节点，调用底层的Unsafe写到JDK底层管道

## Java对象编码过程 ##

为什么我们在pipeline中添加了encoder节点，java对象就转换成netty可以处理的ByteBuf，写到管道里？

我们先看下调用write的code  
![1240 7][]  
业务处理器接受到请求之后，做一些业务处理，返回一个`user`

*  然后，user在pipeline中传递  
    ![AbstractChannel\#][AbstractChannel]

![DefaultChannelPipeline\#][DefaultChannelPipeline]  
![AbstractChannelHandlerContext\#][AbstractChannelHandlerContext]  
![AbstractChannelHandlerContext\#][AbstractChannelHandlerContext 1]

*  情形一  
    ![AbstractChannelHandlerContext\#][AbstractChannelHandlerContext 2]

![AbstractChannelHandlerContext\#][AbstractChannelHandlerContext 3]

*  情形二  
    ![AbstractChannelHandlerContext\#][AbstractChannelHandlerContext 4]

![1240 8][]  
![AbstractChannelHandlerContext\#invokeWrite0][AbstractChannelHandlerContext_invokeWrite0]  
![AbstractChannelHandlerContext\#invokeFlush0][AbstractChannelHandlerContext_invokeFlush0]  
handler 如果不覆盖 flush 方法,就会一直向前传递直到 head 节点  
![1240 9][]

落到 `Encoder`节点，下面是 `Encoder` 的处理流程  
![1240 10][]  
按照简单自定义协议，将Java对象 User 写到传入的参数 out中，这个out到底是什么？

需知`User`对象，从`BizHandler`传入到 `MessageToByteEncoder`时，首先传到 `write`  
![1240 11][]

### 1. 判断当前Handelr是否能处理写入的消息(匹配对象) ###

![1240 12][]  
![1240 13][]  
![1240 14][]

*  判断该对象是否是该类型参数匹配器实例可匹配到的类型  
    ![TypeParameterMatcher\#][TypeParameterMatcher]

![具体实例][1240 15]

### 2 分配内存 ###

![1240 16][]  
![1240 17][]

### 3 编码实现 ###

*  调用`encode`，这里就调回到 `Encoder` 这个`Handler`中  
    ![1240 18][]
 *  其为抽象方法,因此自定义实现类实现编码方法  
    ![1240 19][]

![1240 20][]

### 4 释放对象 ###

*  既然自定义Java对象转换成`ByteBuf`了，那么这个对象就已经无用，释放掉 (当传入的`msg`类型是`ByteBuf`时，就不需要自己手动释放了)  
    ![1240 21][]

![1240 22][]

### 5 传播数据 ###

//112 如果buf中写入了数据，就把buf传到下一个节点,直到 header 节点  
![1240 23][]

### 6 释放内存 ###

//115 否则，释放buf，将空数据传到下一个节点  
// 120 如果当前节点不能处理传入的对象，直接扔给下一个节点处理  
// 127 当buf在pipeline中处理完之后，释放  
![1240 24][]

#### Encoder处理传入的Java对象 ####

*  判断当前`Handler`是否能处理写入的消息
    
     *  如果能处理，进入下面的流程
     *  否则，直接扔给下一个节点处理
 *  将对象强制转换成`Encoder` 可以处理的 `Response`对象
 *  分配一个`ByteBuf`
 *  调用`encoder`，即进入到 Encoder 的 encode方法，该方法是用户代码，用户将数据写入ByteBuf
 *  既然自定义Java对象转换成ByteBuf了，那么这个对象就已经无用了，释放掉(当传入的msg类型是ByteBuf时，无需自己手动释放)
 *  如果buf中写入了数据，就把buf传到下一个节点，否则，释放buf，将空数据传到下一个节点
 *  最后，当buf在pipeline中处理完之后，释放节点

总结就是，`Encoder`节点分配一个`ByteBuf`，调用`encode`方法，将Java对象根据自定义协议写入到ByteBuf，然后再把ByteBuf传入到下一个节点，在我们的例子中，最终会传入到head节点

public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
        unsafe.write(msg, promise);
    }

这里的msg就是前面在Encoder节点中，载有java对象数据的自定义ByteBuf对象

## write - 写buffer队列 ##

![1240 25][]  
![ChannelOutboundInvoker\#][ChannelOutboundInvoker]  
![1240 26][]  
![write(Object msg, boolean flush, ChannelPromise promise)][write_Object msg_ boolean flush_ ChannelPromise promise]  
![1240 27][]  
![1240 28][]  
![1240 29][]  
![HeadContext in DefaultChannelPipeline\#write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise)][HeadContext in DefaultChannelPipeline_write_ChannelHandlerContext ctx_ Object msg_ ChannelPromise promise]  
![Unsafe in Channel\#write(Object msg, ChannelPromise promise)][Unsafe in Channel_write_Object msg_ ChannelPromise promise]  
以下过程分三步讲解  
![1240 30][]

#### direct ByteBuf ####

![1240 31][]  
![AbstractChannel\#filterOutboundMessage(Object msg)][AbstractChannel_filterOutboundMessage_Object msg]

*  首先，调用`assertEventLoop`确保该方法的调用是在`reactor`线程中
 *  然后，调用 `filterOutboundMessage()`，将待写入的对象过滤，把非`ByteBuf`对象和`FileRegion`过滤，把所有的非直接内存转换成直接内存`DirectBuffer`  
    ![1240 32][]

![AbstractNioChannel\#newDirectBuffer][AbstractNioChannel_newDirectBuffer]

#### 插入写队列 ####

*  接下来，估算出需要写入的ByteBuf的size

![1240 33][]

*  最后，调用 ChannelOutboundBuffer 的addMessage(msg, size, promise) 方法，所以，接下来，我们需要重点看一下这个方法干了什么事情  
    ![ChannelOutboundBuffer][]

想要理解上面这段代码，须掌握写缓存中的几个消息指针  
![1240 34][]  
ChannelOutboundBuffer 里面的数据结构是一个单链表结构，每个节点是一个 Entry，Entry 里面包含了待写出ByteBuf 以及消息回调 promise下面分别是

### 三个指针的作用 ###

*  flushedEntry  
    表第一个被写到OS Socket缓冲区中的节点

![ChannelOutboundBuffer][ChannelOutboundBuffer 1]

*  unFlushedEntry  
    表第一个未被写入到OS Socket缓冲区中的节点

![ChannelOutboundBuffer][ChannelOutboundBuffer 2]

*  tailEntry  
    表`ChannelOutboundBuffer`缓冲区的最后一个节点

![ChannelOutboundBuffer][ChannelOutboundBuffer 3]

### 图解过程 ###

*  初次调用write 即 `addMessage` 后  
    ![1240 35][]

`fushedEntry`指向空，`unFushedEntry`和 `tailEntry`都指向新加入节点

*  第二次调用 `addMessage`后  
    ![1240 36][]
 *  第n次调用 `addMessage`后  
    ![1240 37][]

可得,调用n次`addMessage`后

*  `flushedEntry`指针一直指向`null`，表此时尚未有节点需写到Socket缓冲区
 *  `unFushedEntry`后有n个节点，表当前还有n个节点尚未写到Socket缓冲区

#### 设置写状态 ####

![ChannelOutboundBuffer\#addMessage][ChannelOutboundBuffer_addMessage]

*  统计当前有多少字节需要需要被写出  
    ![ChannelOutboundBuffer\#addMessage(Object msg, int size, ChannelPromise promise)][ChannelOutboundBuffer_addMessage_Object msg_ int size_ ChannelPromise promise]
 *  当前缓冲区中有多少待写字节  
    ![ChannelOutboundBuffer\#][ChannelOutboundBuffer 4]

![1240 38][]  
![ChannelConfig\#getWriteBufferHighWaterMark()][ChannelConfig_getWriteBufferHighWaterMark]  
![1240 39][]  
![1240 40][]

*  所以默认不能超过64k  
    ![WriteBufferWaterMark][]

![1240 41][]

*  自旋锁+CAS 操作,通过 pipeline 将事件传播到channelhandler 中监控  
    ![1240 42][]

## flush：刷新buffer队列 ##

### 添加刷新标志并设置写状态 ###

*  不管调用`channel.flush()`，还是`ctx.flush()`，最终都会落地到`pipeline`中的`head`节点  
    ![DefaultChannelPipeline\#flush][DefaultChannelPipeline_flush]
 *  之后进入到`AbstractUnsafe`  
    ![AbstractChannel\#flush()][AbstractChannel_flush]
 *  flush方法中，先调用  
    ![ChannelOutboundBuffer\#addFlush][ChannelOutboundBuffer_addFlush]

![ChannelOutboundBuffer\#decrementPendingOutboundBytes(long size, boolean invokeLater, boolean notifyWritability)][ChannelOutboundBuffer_decrementPendingOutboundBytes_long size_ boolean invokeLater_ boolean notifyWritability]  
![1240 43][]  
![和之前那个实例相同,不再赘述][1240 44]

*  结合前面的图来看，上述过程即  
    首先拿到 `unflushedEntry` 指针，然后将`flushedEntry`指向`unflushedEntry`所指向的节点，调用完毕后

![1240 45][]

### 遍历 buffer 队列,过滤bytebuf ###

*  接下来，调用 `flush0()`  
    ![1240 46][]
 *  发现这里的核心代码就一个 `doWrite`  
    ![AbstractChannel\#][AbstractChannel 1]

# AbstractNioByteChannel #

*  继续跟

protected void doWrite(ChannelOutboundBuffer in) throws Exception {
        int writeSpinCount = -1;
    
        boolean setOpWrite = false;
        for (;;) {
            // 拿到第一个需要flush的节点的数据
            Object msg = in.current();
    
            if (msg instanceof ByteBuf) {
                boolean done = false;
                long flushedAmount = 0;
                // 拿到自旋锁迭代次数
                if (writeSpinCount == -1) {
                    writeSpinCount = config().getWriteSpinCount();
                }
                // 自旋，将当前节点写出
                for (int i = writeSpinCount - 1; i >= 0; i --) {
                    int localFlushedAmount = doWriteBytes(buf);
                    if (localFlushedAmount == 0) {
                        setOpWrite = true;
                        break;
                    }
    
                    flushedAmount += localFlushedAmount;
                    if (!buf.isReadable()) {
                        done = true;
                        break;
                    }
                }
    
                in.progress(flushedAmount);
    
                // 写完之后，将当前节点删除
                if (done) {
                    in.remove();
                } else {
                    break;
                }
            } 
        }
    }

*  第一步，调用`current()`先拿到第一个需要`flush`的节点的数据  
    ![ChannelOutboundBuffer\#current][ChannelOutboundBuffer_current]
 *  第二步,拿到自旋锁的迭代次数  
    ![1240 47][]

*  第三步 调用 JDK 底层 API 进行自旋写  
    自旋的方式将`ByteBuf`写到JDK NIO的`Channel`

强转为ByteBuf，若发现没有数据可读，直接删除该节点  
![1240 48][]

*  拿到自旋锁迭代次数

![image.png][]

*  在并发编程中使用自旋锁可以提高内存使用率和写的吞吐量,默认值为16  
    ![ChannelConfig][]
 *  继续看源码  
    ![1240 49][]

![AbstractNioByteChannel\#][AbstractNioByteChannel]

*  `javaChannel()`，表明 JDK NIO Channel 已介入此次事件  
    ![NioSocketChannel\#][NioSocketChannel]

![ByteBuf\#readBytes(GatheringByteChannel out, int length)][ByteBuf_readBytes_GatheringByteChannel out_ int length]

*  得到向JDK 底层已经写了多少字节  
    ![PooledDirectByteBuf\#][PooledDirectByteBuf]

![1240 50][]

*  从 Netty 的 bytebuf 写到 JDK 底层的 bytebuffer  
    ![1240 51][]

![1240 52][]

*  第四步,删除该节点  
    节点的数据已经写入完毕，接下来就需要删除该节点

![1240 53][]  
首先拿到当前被`flush`掉的节点(`flushedEntry`所指)  
然后拿到该节点的回调对象 `ChannelPromise`, 调用 `removeEntry()`移除该节点  
![1240 54][]  
这里是逻辑移除，只是将flushedEntry指针移到下个节点，调用后  
![1240 55][]  
随后，释放该节点数据的内存，调用`safeSuccess`回调，用户代码可以在回调里面做一些记录，下面是一段Example

ctx.write(xx).addListener(new GenericFutureListener<Future<? super Void>>() {
        @Override
        public void operationComplete(Future<? super Void> future) throws Exception {
           // 回调 
        }
    })

最后，调用 `recycle`，将当前节点回收

## writeAndFlush: 写队列并刷新 ##

`writeAndFlush`在某个`Handler`中被调用之后，最终会落到 `TailContext`节点  
![1240 56][]

public ChannelFuture writeAndFlush(Object msg, ChannelPromise promise) {
        write(msg, true, promise);
    
        return promise;
    }

![AbstractChannelHandlerContext\#][AbstractChannelHandlerContext 5]  
![AbstractChannelHandlerContext\#][AbstractChannelHandlerContext 6]

最终，通过一个`boolean`变量，表示是调用`invokeWriteAndFlush`，还是`invokeWrite`，`invokeWrite`便是我们上文中的write过程  
![AbstractChannelHandlerContext\#][AbstractChannelHandlerContext 7]  
可以看到，最终调用的底层方法和单独调用`write`和`flush`一样的  
![1240 57][]  
![1240 58][]  
由此看来，`invokeWriteAndFlush`基本等价于`write`之后再来一次`flush`

# 总结 #

*  调用`write`并没有将数据写到Socket缓冲区中，而是写到了一个单向链表的数据结构中，`flush`才是真正的写出
 *  `writeAndFlush`等价于先将数据写到netty的缓冲区，再将netty缓冲区中的数据写到Socket缓冲区中，写的过程与并发编程类似，用自旋锁保证写成功
 *  netty中的缓冲区中的ByteBuf为DirectByteBuf  
    ![1240 59][]

## 当 BizHandler 通过 writeAndFlush 方法将自定义对象往前传播时,其实可以拆分成两个过程 ##

*  通过 pipeline逐渐往前传播,传播到其中的一个 encode 节点后,其负责重写 write 方法将自定义的对象转化为 ByteBuf,接着继续调用 write 向前传播
 *  pipeline中的编码器原理是创建一个`ByteBuf`,将Java对象转换为`ByteBuf`，然后再把`ByteBuf`继续向前传递,若没有再重写了,最终会传播到 head 节点,其中缓冲区列表拿到缓存写到 JDK 底层 ByteBuffer

[1240]: /images/20220213/f183c1759f824b528cb532f1c1b990af.png
[1240 1]: /images/20220213/7fe5a98ba92b450fabd5b630c602233a.png
[MessageToByteEncoder API]: /images/20220213/37c32596abb44fd398333b99b812453c.png
[ShortToByteEncoder]: /images/20220213/a0a8e1e213fc436987cfbb0d6315d987.png
[1240 2]: /images/20220213/39f14a6b36c747e88f54a449887b75f2.png
[1240 3]: /images/20220213/7dc3138ead474303ba228ea5cb1ad67d.png
[1240 4]: /images/20220213/a582858b81f0433da4cf4801935590f7.png
[MessageToMessageEncoderAPI]: /images/20220213/a0029296ad9945dbb1dff12d85acbd23.png
[1240 5]: /images/20220213/3d72ee62d8a34407a41a17b2242e04ce.png
[IntegerToStringEncoder]: /images/20220213/ae8a21257712448abb8dff93ddcfd0c8.png
[1240 6]: /images/20220213/e2518c4301d7499a885058eaf88ca82b.png
[pipeline]: /images/20220213/acec8cd83ff84cebb2002ff62fa57a47.png
[1240 7]: /images/20220213/c431772923b24838a33642107e0eafb0.png
[AbstractChannel]: /images/20220213/3f2205e1975f444cb9a9a91ecab52ec2.png
[DefaultChannelPipeline]: /images/20220213/08f02e4412bc4b8ca820ccc7b17460de.png
[AbstractChannelHandlerContext]: /images/20220213/a5a5e3751ae44f6196c29711d9f33555.png
[AbstractChannelHandlerContext 1]: /images/20220213/c8e6bf6e8a43473b87a50e7f763575a6.png
[AbstractChannelHandlerContext 2]: /images/20220213/3befd18dc076409eaa0a523121a11906.png
[AbstractChannelHandlerContext 3]: /images/20220213/a330b7e6e19d4c7281a8b63995d7e5c2.png
[AbstractChannelHandlerContext 4]: /images/20220213/c7aec8a3e94b4ee18e5662c40df83a59.png
[1240 8]: /images/20220213/8d0e527260b6454784dda2dd1dcd8b88.png
[AbstractChannelHandlerContext_invokeWrite0]: /images/20220213/0bfca16bcf534e06b7a74eedc9d569fa.png
[AbstractChannelHandlerContext_invokeFlush0]: /images/20220213/af3afe90452945d18694403ccffbfa32.png
[1240 9]: /images/20220213/5e02a85570b846379efc1ea9431f8a6a.png
[1240 10]: /images/20220213/ad3bc43176784d37b9ac5e959e53046d.png
[1240 11]: /images/20220213/36722d5bf55d4e6cba2d2535b919951e.png
[1240 12]: /images/20220213/57ea4f95bf2d4d8f902c247512bdd028.png
[1240 13]: /images/20220213/1627a0913df74804b5e2d58ba4d845ed.png
[1240 14]: /images/20220213/13308b33f75540c9b0ad38626bfba000.png
[TypeParameterMatcher]: /images/20220213/4b5d8832e45b4455bcf61edb68bd4a42.png
[1240 15]: /images/20220213/32e2b35c94ce4f96b220eeb8ef81357d.png
[1240 16]: /images/20220213/64f09d5ec0f74e4192659858e16b5168.png
[1240 17]: /images/20220213/6ebae21f4fe04af7a87ec408cd72499e.png
[1240 18]: /images/20220213/3ef241b0b5eb41b5b87a38e763b8a4bd.png
[1240 19]: /images/20220213/d15bbbe2c17d4c5e954e260e10583a79.png
[1240 20]: /images/20220213/480c314ecb544ff7aa40f3e991e2778b.png
[1240 21]: /images/20220213/368b221a3fe847a4979680a716dc3c83.png
[1240 22]: /images/20220213/d8b7b843aece4918a678a78cfd2257c8.png
[1240 23]: /images/20220213/407a75b730874d41a1e0ba6e797512a8.png
[1240 24]: /images/20220213/5b2a990fe4ff42ac97387943709fb9a8.png
[1240 25]: /images/20220213/5f28339938ae4609a37ef25c569b6d7f.png
[ChannelOutboundInvoker]: /images/20220213/a8bab7e08c8c449daabfd2398c8c76db.png
[1240 26]: /images/20220213/46ed262b614d4d4f8921eebaea2f516f.png
[write_Object msg_ boolean flush_ ChannelPromise promise]: /images/20220213/1007ba32e06c461486ffb2fc471bccf0.png
[1240 27]: /images/20220213/057e3d241b784bb19e1e9651e21fed4f.png
[1240 28]: /images/20220213/8209fee7310b41e38685ee12808d8eb1.png
[1240 29]: /images/20220213/308a4eb8faae42dd9d1e987c04d0a57a.png
[HeadContext in DefaultChannelPipeline_write_ChannelHandlerContext ctx_ Object msg_ ChannelPromise promise]: /images/20220213/f8b9da11033a4ae7aba25b6e7367d5f6.png
[Unsafe in Channel_write_Object msg_ ChannelPromise promise]: /images/20220213/ad87837245814b6aa79d1a63dfd3ff55.png
[1240 30]: /images/20220213/69fbcbfa665b4180bf2f61ec71b57aa6.png
[1240 31]: /images/20220213/0ab8f41802e64aff912d7a8f7966862b.png
[AbstractChannel_filterOutboundMessage_Object msg]: /images/20220213/36493ca23ebe4b39a494b3db229b3e29.png
[1240 32]: /images/20220213/1cf7455db29140f6bfdbb3bc2b8e8e1e.png
[AbstractNioChannel_newDirectBuffer]: /images/20220213/687b382e207a4b7eba2bef7209083290.png
[1240 33]: /images/20220213/a319cf3ebe73453ab2c8753b61a50c0f.png
[ChannelOutboundBuffer]: /images/20220213/196b630f27c24c07b467de769a0d26e8.png
[1240 34]: /images/20220213/44572e1fc4f04e2699206c8c2d79ca1a.png
[ChannelOutboundBuffer 1]: /images/20220213/dd6879efa9d64802a06145cb8e2b2374.png
[ChannelOutboundBuffer 2]: /images/20220213/67f30cc4df2847fdb3c2ef84e79c0648.png
[ChannelOutboundBuffer 3]: /images/20220213/fafec68e0de1409ea122f364243a7465.png
[1240 35]: /images/20220213/e15cea140dd6403c8aeb863b58e614da.png
[1240 36]: /images/20220213/6445645455a04209824809ef59522978.png
[1240 37]: /images/20220213/48fa863593914a9f95f37993b3ee058a.png
[ChannelOutboundBuffer_addMessage]: /images/20220213/ca733df6412e4ef195eb7504c0db0374.png
[ChannelOutboundBuffer_addMessage_Object msg_ int size_ ChannelPromise promise]: /images/20220213/b96e54473f524fe19ecceb9fe260d5b7.png
[ChannelOutboundBuffer 4]: /images/20220213/02bae46f2888472587928c2a4c775e21.png
[1240 38]: /images/20220213/916726e1f16a4c979343c78cbdef740b.png
[ChannelConfig_getWriteBufferHighWaterMark]: /images/20220213/a2851c3602824c678f51330d1115ce1f.png
[1240 39]: /images/20220213/ab7449f722c043138cab28904316fd83.png
[1240 40]: /images/20220213/b6765a43ff2f4a8493ab7af9d3be0c27.png
[WriteBufferWaterMark]: /images/20220213/cebd1c01091c4f369d8deb5eb55d9623.png
[1240 41]: /images/20220213/94cdca415c154b1cb54d7a6e9f6f1add.png
[1240 42]: /images/20220213/0d3cf879ff04434ab3fc611710fb70e3.png
[DefaultChannelPipeline_flush]: /images/20220213/af8bd7976f0346688380380a95f65051.png
[AbstractChannel_flush]: /images/20220213/3504257de3314d6ab70515b4e4923ea1.png
[ChannelOutboundBuffer_addFlush]: /images/20220213/a18ac0441f364f9e9dcf998c3da2ee9c.png
[ChannelOutboundBuffer_decrementPendingOutboundBytes_long size_ boolean invokeLater_ boolean notifyWritability]: /images/20220213/6a3533ef87044db1bf4be3db1b6f9d9b.png
[1240 43]: /images/20220213/1671b99f6fb84530808bb5fc1c62e644.png
[1240 44]: /images/20220213/eb46f6108322429f890c812bfd3007c8.png
[1240 45]: /images/20220213/b3d4bdf16a4246d2af264fafa9215111.png
[1240 46]: /images/20220213/fc8838aaf4e3421eadba182cff9a8b48.png
[AbstractChannel 1]: /images/20220213/467eb31c3c584839bb79b2b4f38e9dbd.png
[ChannelOutboundBuffer_current]: /images/20220213/ddf45fa7aca3481a9405a719dcf454d7.png
[1240 47]: /images/20220213/f5c0ad506cbc42f0aea01ed6017dada7.png
[1240 48]: /images/20220213/64913241146e45cc81b70b212ad21736.png
[image.png]: /images/20220213/193fb2ebe758410b95adec8ceb0610c9.png
[ChannelConfig]: /images/20220213/4c0f99e3c6cd4e939c0b1368154321b7.png
[1240 49]: /images/20220213/63936997f2204f20a6ce2d515dd054e8.png
[AbstractNioByteChannel]: /images/20220213/9c97f35e1b86498887098282f099b268.png
[NioSocketChannel]: /images/20220213/8fe25350d1df4b388acd62f032f01b72.png
[ByteBuf_readBytes_GatheringByteChannel out_ int length]: /images/20220213/6638aed093344a76bb3f527b51a50fe7.png
[PooledDirectByteBuf]: /images/20220213/4fb697dcc9fa42b5b1062c4849baac56.png
[1240 50]: /images/20220213/5642f67d1df4471d8033281c0ac3d397.png
[1240 51]: /images/20220213/dfeb5bb4489944d1a7ce2e0f16e32e66.png
[1240 52]: /images/20220213/19025e7e50ef445fbca5d2f116486c7c.png
[1240 53]: /images/20220213/32cb3b20d1f34182b490ad9160220a8c.png
[1240 54]: /images/20220213/7fedaa7318e745059b41316d4591f2c3.png
[1240 55]: /images/20220213/d543b19910344898a75b923f99681a23.png
[1240 56]: /images/20220213/6e30f42dccdc4e25af35ac65e4ad1e8f.png
[AbstractChannelHandlerContext 5]: /images/20220213/cd590875f4c04208a5c67bf472b848ba.png
[AbstractChannelHandlerContext 6]: /images/20220213/c78d762b27f341969b478880dcc7b0a9.png
[AbstractChannelHandlerContext 7]: /images/20220213/18dcdf2b8e824c469e3275b92093bcb3.png
[1240 57]: /images/20220213/350916c5023b4bb6a55524da318e8582.png
[1240 58]: /images/20220213/1d237ce879eb4ea6a5148215ad7b5c2b.png
[1240 59]: /images/20220213/ac379bdf7f4541c2bbdc9fc23a35186b.png