Netty这一篇入门

青旅半醒 2022-04-08 08:50 182阅读 0赞

本文基于Netty4.1展开介绍相关理论模型，使用场景，基本组件、整体架构，**知其然且知其所以然**，希望给大家在实际开发实践、学习开源项目提供参考。

**Netty简介**

Netty是 一个异步事件驱动的网络应用程序框架，用于快速开发可维护的高性能协议服务器和客户端。

**JDK原生NIO程序的问题**

JDK原生也有一套网络应用程序API，但是存在一系列问题，主要如下：

*  NIO的类库和API繁杂，使用麻烦，你需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等
 *  需要具备其它的额外技能做铺垫，例如熟悉Java多线程编程，因为NIO编程涉及到Reactor模式，你必须对多线程和网路编程非常熟悉，才能编写出高质量的NIO程序
 *  可靠性能力补齐，开发工作量和难度都非常大。例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等等，NIO编程的特点是功能开发相对容易，但是可靠性能力补齐工作量和难度都非常大
 *  JDK NIO的BUG，例如臭名昭著的epoll bug，它会导致Selector空轮询，最终导致CPU 100%。官方声称在JDK1.6版本的update18修复了该问题，但是直到JDK1.7版本该问题仍旧存在，只不过该bug发生概率降低了一些而已，它并没有被根本解决

**Netty的特点**

Netty的对JDK自带的NIO的API进行封装，解决上述问题，主要特点有：

*  设计优雅  
    适用于各种传输类型的统一API - 阻塞和非阻塞Socket  
    基于灵活且可扩展的事件模型，可以清晰地分离关注点  
    高度可定制的线程模型 - 单线程，一个或多个线程池  
    真正的无连接数据报套接字支持（自3.1起）
 *  使用方便  
    详细记录的Javadoc，用户指南和示例  
    没有其他依赖项，JDK 5（Netty 3.x）或6（Netty 4.x）就足够了
 *  高性能  
    吞吐量更高，延迟更低  
    减少资源消耗  
    最小化不必要的内存复制
 *  安全  
    完整的SSL / TLS和StartTLS支持
 *  社区活跃，不断更新  
    社区活跃，版本迭代周期短，发现的BUG可以被及时修复，同时，更多的新功能会被加入

**Netty常见使用场景**

**Netty常见的使用场景如下：**

*  互联网行业  
    在分布式系统中，各个节点之间需要远程服务调用，高性能的RPC框架必不可少，Netty作为异步高新能的通信框架,往往作为基础通信组件被这些RPC框架使用。  
    典型的应用有：阿里分布式服务框架Dubbo的RPC框架使用Dubbo协议进行节点间通信，Dubbo协议默认使用Netty作为基础通信组件，用于实现各进程节点之间的内部通信。
 *  游戏行业  
    无论是手游服务端还是大型的网络游戏，Java语言得到了越来越广泛的应用。Netty作为高性能的基础通信组件，它本身提供了TCP/UDP和HTTP协议栈。  
    非常方便定制和开发私有协议栈，账号登录服务器，地图服务器之间可以方便的通过Netty进行高性能的通信
 *  大数据领域  
    经典的Hadoop的高性能通信和序列化组件Avro的RPC框架，默认采用Netty进行跨界点通信，它的Netty Service基于Netty框架二次封装实现

有兴趣的读者可以了解一下目前有哪些开源项目使用了 Netty：Related projects

**2 Netty高性能设计**

Netty作为异步事件驱动的网络，高性能之处主要来自于其I/O模型和线程处理模型，前者决定如何收发数据，后者决定如何处理数据

## I/O模型 ##

用什么样的通道将数据发送给对方，BIO、NIO或者AIO，I/O模型在很大程度上决定了框架的性能

### **阻塞I/O** ###

传统阻塞型I/O(BIO)可以用下图表示：(Blocking I/O)

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70][]

**特点**

*  每个请求都需要独立的线程完成数据read，业务处理，数据write的完整操作

**问题**

*  当并发数较大时，需要创建大量线程来处理连接，系统资源占用较大
 *  连接建立后，如果当前线程暂时没有数据可读，则线程就阻塞在read操作上，造成线程资源浪费

### **I/O复用模型** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 1][]

在I/O复用模型中，会用到select，这个函数也会使进程阻塞，但是和阻塞I/O所不同的的，这两个函数可以同时阻塞多个I/O操作，而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数

Netty的非阻塞I/O的实现关键是基于I/O复用模型，这里用Selector对象表示：(Nonblocking I/O)

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 2][]

Netty的IO线程NioEventLoop由于聚合了多路复用器Selector，可以同时并发处理成百上千个客户端连接。当线程从某客户端Socket通道进行读写数据时，若没有数据可用时，该线程可以进行其他任务。线程通常将非阻塞 IO 的空闲时间用于在其他通道上执行 IO 操作，所以单独的线程可以管理多个输入和输出通道。

由于读写操作都是非阻塞的，这就可以充分提升IO线程的运行效率，避免由于频繁I/O阻塞导致的线程挂起，一个I/O线程可以并发处理N个客户端连接和读写操作，这从根本上解决了传统同步阻塞I/O一连接一线程模型，架构的性能、弹性伸缩能力和可靠性都得到了极大的提升。

### **基于buffer** ###

传统的I/O是面向字节流或字符流的，以流式的方式顺序地从一个Stream 中读取一个或多个字节, 因此也就不能随意改变读取指针的位置。

在NIO中, 抛弃了传统的 I/O流, 而是引入了Channel和Buffer的概念. 在NIO中, 只能从Channel中读取数据到Buffer中或将数据 Buffer 中写入到 Channel。

基于buffer操作不像传统IO的顺序操作, NIO 中可以随意地读取任意位置的数据

## 线程模型 ##

数据报如何读取？读取之后的编解码在哪个线程进行，编解码后的消息如何派发，线程模型的不同，对性能的影响也非常大。

### **事件驱动模型** ###

通常，我们设计一个事件处理模型的程序有两种思路

*  轮询方式  
    线程不断轮询访问相关事件发生源有没有发生事件，有发生事件就调用事件处理逻辑。
 *  事件驱动方式  
    发生事件，主线程把事件放入事件队列，在另外线程不断循环消费事件列表中的事件，调用事件对应的处理逻辑处理事件。事件驱动方式也被称为消息通知方式，其实是设计模式中**观察者模式**的思路。

以GUI的逻辑处理为例，说明两种逻辑的不同：

*  轮询方式  
    线程不断轮询是否发生按钮点击事件，如果发生，调用处理逻辑
 *  事件驱动方式  
    发生点击事件把事件放入事件队列，在另外线程消费的事件列表中的事件，根据事件类型调用相关事件处理逻辑

这里借用O'Reilly 大神关于事件驱动模型解释图(事件驱动模型)

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 3][]

主要包括4个基本组件：

*  事件队列（event queue）：接收事件的入口，存储待处理事件
 *  分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元
 *  事件通道（event channel）：分发器与处理器之间的联系渠道
 *  事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作

可以看出，相对传统轮询模式，事件驱动有如下优点：

*  可扩展性好，分布式的异步架构，事件处理器之间高度解耦，可以方便扩展事件处理逻辑
 *  高性能，基于队列暂存事件，能方便并行异步处理事件

### **Reactor线程模型** ###

Reactor是反应堆的意思，Reactor模型，是指通过一个或多个输入同时传递给服务处理器的服务请求的**事件驱动处理模式**。 服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor模式也叫Dispatcher模式，即I/O多了复用统一监听事件，收到事件后分发(Dispatch给某进程)，是编写高性能网络服务器的必备技术之一。

Reactor模型中有2个关键组成：

*  Reactor  
    Reactor在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对IO事件做出反应。 它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人
 *  Handlers  
    处理程序执行I/O事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际官员。Reactor通过调度适当的处理程序来响应I/O事件，处理程序执行非阻塞操作

Reactor模型:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 4][]

取决于Reactor的数量和Hanndler线程数量的不同，Reactor模型有3个变种

*  单Reactor单线程
 *  单Reactor多线程
 *  主从Reactor多线程

可以这样理解，Reactor就是一个执行while (true) \{ selector.select(); …\}循环的线程，会源源不断的产生新的事件，称作反应堆很贴切。

篇幅关系，这里不再具体展开Reactor特性、优缺点比较，有兴趣的读者可以参考我之前另外一篇文章：《理解高性能网络模型》

### **Netty线程模型** ###

Netty主要**基于主从Reactors多线程模型**（如下图）做了一定的修改，其中主从Reactor多线程模型有多个Reactor：MainReactor和SubReactor：

*  MainReactor负责客户端的连接请求，并将请求转交给SubReactor
 *  SubReactor负责相应通道的IO读写请求
 *  非IO请求（具体逻辑处理）的任务则会直接写入队列，等待worker threads进行处理

这里引用Doug Lee大神的Reactor介绍：Scalable IO in Java里面关于主从Reactor多线程模型的图

主从Rreactor多线程模型:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 5][]

特别说明的是：  
虽然Netty的线程模型基于主从Reactor多线程，借用了MainReactor和SubReactor的结构，但是实际实现上，SubReactor和Worker线程在同一个线程池中：

EventLoopGroup bossGroup = new NioEventLoopGroup();
    EventLoopGroup workerGroup = new NioEventLoopGroup();
    ServerBootstrap server = new ServerBootstrap();
    server.group(bossGroup, workerGroup)
    .channel(NioServerSocketChannel.class)

上面代码中的bossGroup 和workerGroup是Bootstrap构造方法中传入的两个对象，这两个group均是线程池

*  bossGroup线程池则只是在bind某个端口后，获得其中一个线程作为MainReactor，专门处理端口的accept事件，**每个端口对应一个boss线程**
 *  workerGroup线程池会被各个SubReactor和worker线程充分利用

### **异步处理** ###

异步的概念和同步相对。当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者。

Netty中的I/O操作是异步的，包括bind、write、connect等操作会简单的返回一个ChannelFuture，调用者并不能立刻获得结果，通过Future-Listener机制，用户可以方便的主动获取或者通过通知机制获得IO操作结果。

当future对象刚刚创建时，处于非完成状态，调用者可以通过返回的ChannelFuture来获取操作执行的状态，注册监听函数来执行完成后的操，常见有如下操作：

*  通过isDone方法来判断当前操作是否完成
 *  通过isSuccess方法来判断已完成的当前操作是否成功
 *  通过getCause方法来获取已完成的当前操作失败的原因
 *  通过isCancelled方法来判断已完成的当前操作是否被取消
 *  通过addListener方法来注册监听器，当操作已完成(isDone方法返回完成)，将会通知指定的监听器；如果future对象已完成，则理解通知指定的监听器

例如下面的的代码中绑定端口是异步操作，当绑定操作处理完，将会调用相应的监听器处理逻辑

serverBootstrap.bind(port).addListener(future -> {
           if (future.isSuccess()) {
               System.out.println(new Date() + ": 端口[" + port + "]绑定成功!");
           } else {
               System.err.println("端口[" + port + "]绑定失败!");
           }
       });

相比传统阻塞I/O，执行I/O操作后线程会被阻塞住, 直到操作完成；异步处理的好处是不会造成线程阻塞，线程在I/O操作期间可以执行别的程序，在高并发情形下会更稳定和更高的吞吐量。

Netty架构设计

前面介绍完Netty相关一些理论介绍，下面从功能特性、模块组件、运作过程来介绍Netty的架构设计

## 功能特性 ##

Netty功能特性图:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 6][]

*  传输服务  
    支持BIO和NIO
 *  容器集成  
    支持OSGI、JBossMC、Spring、Guice容器
 *  协议支持  
    HTTP、Protobuf、二进制、文本、WebSocket等一系列常见协议都支持。  
    还支持通过实行编码解码逻辑来实现自定义协议
 *  Core核心  
    可扩展事件模型、通用通信API、支持零拷贝的ByteBuf缓冲对象

## 模块组件 ##

### **Bootstrap、ServerBootstrap** ###

Bootstrap意思是引导，一个Netty应用通常由一个Bootstrap开始，主要作用是配置整个Netty程序，串联各个组件，Netty中Bootstrap类是客户端程序的启动引导类，ServerBootstrap是服务端启动引导类。

### **Future、ChannelFuture** ###

正如前面介绍，在Netty中所有的IO操作都是异步的，不能立刻得知消息是否被正确处理，但是可以过一会等它执行完成或者直接注册一个监听，具体的实现就是通过Future和ChannelFutures，他们可以注册一个监听，当操作执行成功或失败时监听会自动触发注册的监听事件。

### **Channel** ###

Netty网络通信的组件，能够用于执行网络I/O操作。  
Channel为用户提供：

*  当前网络连接的通道的状态（例如是否打开？是否已连接？）
 *  网络连接的配置参数 （例如接收缓冲区大小）
 *  提供异步的网络I/O操作(如建立连接，读写，绑定端口)，异步调用意味着任何I / O调用都将立即返回，并且不保证在调用结束时所请求的I / O操作已完成。调用立即返回一个ChannelFuture实例，通过注册监听器到ChannelFuture上，可以I / O操作成功、失败或取消时回调通知调用方。
 *  支持关联I/O操作与对应的处理程序
    
    不同协议、不同的阻塞类型的连接都有不同的 Channel 类型与之对应，下面是一些常用的 Channel 类型
 *  NioSocketChannel，异步的客户端 TCP Socket 连接
 *  NioServerSocketChannel，异步的服务器端 TCP Socket 连接
 *  NioDatagramChannel，异步的 UDP 连接
 *  NioSctpChannel，异步的客户端 Sctp 连接
 *  NioSctpServerChannel，异步的 Sctp 服务器端连接

这些通道涵盖了 UDP 和 TCP网络 IO以及文件 IO.

### **Selector** ###

Netty基于Selector对象实现I/O多路复用，通过 Selector, 一个线程可以监听多个连接的Channel事件, 当向一个Selector中注册Channel 后，Selector 内部的机制就可以自动不断地查询(select) 这些注册的Channel是否有已就绪的I/O事件(例如可读, 可写, 网络连接完成等)，这样程序就可以很简单地使用一个线程高效地管理多个 Channel 。

### **NioEventLoop** ###

NioEventLoop中维护了一个线程和任务队列，支持异步提交执行任务，线程启动时会调用NioEventLoop的run方法，执行I/O任务和非I/O任务：

*  I/O任务  
    即selectionKey中ready的事件，如accept、connect、read、write等，由processSelectedKeys方法触发。
 *  非IO任务  
    添加到taskQueue中的任务，如register0、bind0等任务，由runAllTasks方法触发。

两种任务的执行时间比由变量ioRatio控制，默认为50，则表示允许非IO任务执行的时间与IO任务的执行时间相等。

### **NioEventLoopGroup** ###

NioEventLoopGroup，主要管理eventLoop的生命周期，可以理解为一个线程池，内部维护了一组线程，每个线程(NioEventLoop)负责处理多个Channel上的事件，而一个Channel只对应于一个线程。

### **ChannelHandler** ###

ChannelHandler是一个接口，处理I / O事件或拦截I / O操作，并将其转发到其ChannelPipeline(业务处理链)中的下一个处理程序。

ChannelHandler本身并没有提供很多方法，因为这个接口有许多的方法需要实现，方便使用期间，可以继承它的子类：

*  ChannelInboundHandler用于处理入站I / O事件
 *  ChannelOutboundHandler用于处理出站I / O操作

或者使用以下适配器类：

*  ChannelInboundHandlerAdapter用于处理入站I / O事件
 *  ChannelOutboundHandlerAdapter用于处理出站I / O操作
 *  ChannelDuplexHandler用于处理入站和出站事件

### **ChannelHandlerContext** ###

保存Channel相关的所有上下文信息，同时关联一个ChannelHandler对象

### **ChannelPipline** ###

保存ChannelHandler的List，用于处理或拦截Channel的入站事件和出站操作。 ChannelPipeline实现了一种高级形式的拦截过滤器模式，使用户可以完全控制事件的处理方式，以及Channel中各个的ChannelHandler如何相互交互。

下图引用Netty的Javadoc4.1中ChannelPipline的说明，描述了ChannelPipeline中ChannelHandler通常如何处理I/O事件。 I/O事件由ChannelInboundHandler或ChannelOutboundHandler处理，并通过调用ChannelHandlerContext中定义的事件传播方法（例如ChannelHandlerContext.fireChannelRead（Object）和ChannelOutboundInvoker.write（Object））转发到其最近的处理程序。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 7][]

入站事件由自下而上方向的入站处理程序处理，如图左侧所示。 入站Handler处理程序通常处理由图底部的I / O线程生成的入站数据。 通常通过实际输入操作（例如SocketChannel.read（ByteBuffer））从远程读取入站数据。

出站事件由上下方向处理，如图右侧所示。 出站Handler处理程序通常会生成或转换出站传输，例如write请求。 I/O线程通常执行实际的输出操作，例如SocketChannel.write（ByteBuffer）。

在 Netty 中每个 Channel 都有且仅有一个 ChannelPipeline 与之对应, 它们的组成关系如下:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 8][]

一个 Channel 包含了一个 ChannelPipeline, 而 ChannelPipeline 中又维护了一个由 ChannelHandlerContext 组成的双向链表, 并且每个 ChannelHandlerContext 中又关联着一个 ChannelHandler。入站事件和出站事件在一个双向链表中，入站事件会从链表head往后传递到最后一个入站的handler，出站事件会从链表tail往前传递到最前一个出站的handler，两种类型的handler互不干扰。

**工作原理架构**

初始化并启动Netty服务端过程如下：

public static void main(String[] args) {
           // 创建mainReactor
           NioEventLoopGroup boosGroup = new NioEventLoopGroup();
           // 创建工作线程组
           NioEventLoopGroup workerGroup = new NioEventLoopGroup();
    
           final ServerBootstrap serverBootstrap = new ServerBootstrap();
           serverBootstrap 
                    // 组装NioEventLoopGroup 
                   .group(boosGroup, workerGroup)
                    // 设置channel类型为NIO类型
                   .channel(NioServerSocketChannel.class)
                   // 设置连接配置参数
                   .option(ChannelOption.SO_BACKLOG, 1024)
                   .childOption(ChannelOption.SO_KEEPALIVE, true)
                   .childOption(ChannelOption.TCP_NODELAY, true)
                   // 配置入站、出站事件handler
                   .childHandler(new ChannelInitializer<NioSocketChannel>() {
                       @Override
                       protected void initChannel(NioSocketChannel ch) {
                           // 配置入站、出站事件channel
                           ch.pipeline().addLast(...);
                           ch.pipeline().addLast(...);
                       }
       });
    
           // 绑定端口
           int port = 8080;
           serverBootstrap.bind(port).addListener(future -> {
               if (future.isSuccess()) {
                   System.out.println(new Date() + ": 端口[" + port + "]绑定成功!");
               } else {
                   System.err.println("端口[" + port + "]绑定失败!");
               }
           });
    }

*  基本过程如下：
 *  1 初始化创建2个NioEventLoopGroup，其中boosGroup用于Accetpt连接建立事件并分发请求，   
    workerGroup用于处理I/O读写事件和业务逻辑
 *  2  基于ServerBootstrap(服务端启动引导类)，配置EventLoopGroup、Channel类型，连接参数、配置入站、出站事件handler
 *  3 绑定端口，开始工作

结合上面的介绍的Netty Reactor模型，介绍服务端Netty的工作架构图：

(服务端Netty Reactor工作架构图):

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 9][]

server端包含1个Boss NioEventLoopGroup和1个Worker NioEventLoopGroup，NioEventLoopGroup相当于1个事件循环组，这个组里包含多个事件循环NioEventLoop，每个NioEventLoop包含1个selector和1个事件循环线程。

每个Boss NioEventLoop循环执行的任务包含3步：

*  1 轮询accept事件
 *  2 处理accept I/O事件，与Client建立连接，生成NioSocketChannel，并将NioSocketChannel注册到某个Worker NioEventLoop的Selector上  
    \*3 处理任务队列中的任务，runAllTasks。任务队列中的任务包括用户调用eventloop.execute或schedule执行的任务，或者其它线程提交到该eventloop的任务。

每个Worker NioEventLoop循环执行的任务包含3步：

*  1 轮询read、write事件；
 *  2 处I/O事件，即read、write事件，在NioSocketChannel可读、可写事件发生时进行处理
 *  3 处理任务队列中的任务，runAllTasks。

其中任务队列中的task有3种典型使用场景

*  1 用户程序自定义的普通任务

ctx.channel().eventLoop().execute(new Runnable() {
       @Override
       public void run() {
           //...
       }
    });

*  2 非当前reactor线程调用channel的各种方法  
    例如在推送系统的业务线程里面，根据用户的标识，找到对应的channel引用，然后调用write类方法向该用户推送消息，就会进入到这种场景。最终的write会提交到任务队列中后被异步消费。
 *  3 用户自定义定时任务

ctx.channel().eventLoop().schedule(new Runnable() {
       @Override
       public void run() {
    
       }
    }, 60, TimeUnit.SECONDS);

**总结**

现在稳定推荐使用的主流版本还是Netty4，Netty5 中使用了 ForkJoinPool，增加了代码的复杂度，但是对性能的改善却不明显，所以这个版本不推荐使用，官网也没有提供下载链接。

Netty 入门门槛相对较高，其实是因为这方面的资料较少，并不是因为他有多难，大家其实都可以像搞透 Spring 一样搞透 Netty。在学习之前，建议先理解透整个框架原理结构，运行过程，可以少走很多弯路。

# 参考资料 #

Netty入门与实战：仿写微信 IM 即时通讯系统

Netty官网

Netty 4.x学习笔记 - 线程模型

Netty入门与实战

理解高性能网络模型

Netty基本原理介绍

software-architecture-patterns.pdf

Netty高性能之道 —— 李林锋

《Netty In Action》

《Netty权威指南》

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70]: /images/20220407/0450499b1d4845c8980d7b4189324310.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 1]: /images/20220407/1fcf4ac172cc4aeea34cc6066042d960.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 2]: /images/20220407/5ce15b62ce784c5abd31e113e6f09629.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 3]: /images/20220407/f2e75f67a36e4a1b98fb8e23e1cf154c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 4]: /images/20220407/8c38271b836842f69e4c578edb7635e4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 5]: /images/20220407/f10039ff191a46349a70b63966dbc299.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 6]: /images/20220407/00f00d1394244570813acb5f9435065b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 7]: /images/20220407/0d311fa86a5848128148e06e33e6afe8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 8]: /images/20220407/d0e824b3731b44c296dfed5b22c84ad2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3czNzI0MjYwOTY_size_16_color_FFFFFF_t_70 9]: /images/20220407/1de5f2c7b9034e70a4e67a4ed123380f.png