背景

Netty 框架的特点

Netty 的一个特点就是入门相对比较容易，但是真正掌握并精通是非常困难的，原因有如下几个：

涉及的知识面比较广：Netty 作为一个高性能的 NIO 通信框架，涉及到的知识点包括网络通信、多线程编程、序列化和反序列化、异步和同步编程模型、SSL/TLS 安全、内存池、HTTP、MQTT 等各种协议栈，这些知识点在 Java 语言中本身就是难点和重点，如果对这些基础知识掌握不扎实，是很难真正掌握好 Netty 的。

调试比较困难：因为大量使用异步编程接口，以及消息处理过程中的各种线程切换，相比于传统同步代码，调试难度比较大。

类继承层次比较深，有些代码很晦涩（例如内存池、Reactor 线程模型等），对于初学者而言，通过阅读代码来掌握 Netty 难度还是比较大的。

代码规模庞大：目前，Netty 的代码规模已经非常庞大，特别是协议栈部分，提供了对 HTTP/2、MQTT、WebSocket、SMTP 等多种协议的支持，相关代码非常多。如果学习方式不当，抓不住重点，全量阅读 Netty 源码，既耗时又很难吃透，很容易半途而废。

资料比较零散，缺乏实践相关的案例：网上各种 Netty 的资料非常多，但是以理论讲解为主，Netty 在各行业中的应用、问题定位技巧以及案例实践方面的资料很少，缺乏系统性的实践总结，也是 Netty 学习的一大痛点。

初学者常见问题

对于很多初学者，在学习过程中经常会遇到如下几个问题：

相关领域知识的储备不足：想了解学习 Netty 需要储备哪些技能，掌握哪些知识点，有什么学习技巧可以更快的掌握 Netty。由于对 Java 多线程编程、Socket 通信、TCP/IP 协议栈等知识掌握不扎实，后续在学习 Netty 的过程中会遇到很多困难。

理论学习完，实践遇到难题：学习完理论知识之后，想在实际项目中使用，但是真正跟具体项目结合在一起解决实际问题时，又感觉比较棘手，不知道自己使用的方式是否最优，希望能够多学一些案例实践方面的知识，以便更好的在业务中使用 Netty。

出了问题不会定位：在项目中遇到了问题，但是由于对 Netty 底层细节掌握不扎实，无法有效的定位并解决问题，只能靠网上搜索相关案例来参考，问题解决效率比较低，甚至束手无策。

Netty 学习策略

Netty 入门相对简单，但是要在实际项目中用好它，出了问题能够快速定位和解决，却并非易事。只有在入门阶段扎实的学好 Netty，后面使用才能够得心应手。

入门知识准备

Java NIO 类库

需要熟悉和掌握的类库主要包括：

缓冲区 Buffer。

通道 Channel。

多路复用器 Selector。

首先介绍缓冲区（Buffer）的概念，Buffer 是一个对象，它包含一些要写入或者要读出的数据。在 NIO 类库中加入 Buffer 对象，体现了新库与原 I/O 的一个重要区别。在面向流的 I/O 中，可以将数据直接写入或者将数据直接读到 Stream 对象中。在 NIO 库中，所有数据都是用缓冲区处理的。在读取数据时，它是直接读到缓冲区中的；在写入数据时，写入到缓冲区中。任何时候访问 NIO 中的数据，都是通过缓冲区进行操作。

缓冲区实质上是一个数组。通常它是一个字节数组（ByteBuffer），也可以使用其他种类的数组。但是一个缓冲区不仅仅是一个数组，缓冲区提供了对数据的结构化访问以及维护读写位置（limit）等信息。

最常用的缓冲区是 ByteBuffer，一个 ByteBuffer 提供了一组功能用于操作 byte 数组。比较常用的就是 get 和 put 系列方法，如下所示：

图 1 ByteBuffer 常用接口定义

Channel 是一个通道，可以通过它读取和写入数据，它就像自来水管一样，网络数据通过 Channel 读取和写入。通道与流的不同之处在于通道是双向的，流只是在一个方向上移动（一个流必须是 InputStream 或者 OutputStream 的子类），而且通道可以用于读、写或者同时用于读写。因为 Channel 是全双工的，所以它可以比流更好地映射底层操作系统的 API。特别是在 UNIX 网络编程模型中，底层操作系统的通道都是全双工的，同时支持读写操作。

比较常用的 Channel 是 SocketChannel 和 ServerSocketChannel，其中 SocketChannel 的继承关系如下图所示：

图 2 SocketChannel 继承关系

Selector 是 Java NIO 编程的基础，熟练地掌握 Selector 对于掌握 NIO 编程至关重要。多路复用器提供选择已经就绪的任务的能力。简单来讲，Selector 会不断地轮询注册在其上的 Channel，如果某个 Channel 上面有新的 TCP 连接接入、读和写事件，这个 Channel 就处于就绪状态，会被 Selector 轮询出来，然后通过 SelectionKey 可以获取就绪 Channel 的集合，进行后续的 I/O 操作。

Java 多线程编程

作为异步事件驱动、高性能的 NIO 框架，Netty 代码中大量运用了 Java 多线程编程技巧，熟练掌握多线程编程是掌握 Netty 的必备条件。

需要掌握的多线程编程相关知识包括：

Java 内存模型。

关键字 synchronized。

读写锁。

volatile 的正确使用。

CAS 指令和原子类。

JDK 线程池以及各种默认实现。

以关键字 synchronized 为例，它可以保证在同一时刻，只有一个线程可以执行某一个方法或者代码块。同步的作用不仅仅是互斥，它的另一个作用就是共享可变性，当某个线程修改了可变数据并释放锁后，其它的线程可以获取被修改变量的最新值。如果没有正确的同步，这种修改对其它线程是不可见的。

下面我们就通过对 Netty 的源码进行分析，看看 Netty 是如何对并发可变数据进行正确同步的。以 AbstractBootstrap 为例进行分析，首先看它的 option 方法：

这个方法的作用是设置 ServerBootstrap 或 Bootstrap 的 Socket 属性，它的属性集定义如下：

由于是非线程安全的 LinkedHashMap, 所以如果多线程创建、访问和修改 LinkedHashMap 时，必须在外部进行必要的同步。由于 ServerBootstrap 和 Bootstrap 被调用方线程创建和使用，无法保证它的方法和成员变量不被并发访问。因此，作为成员变量的 options 必须进行正确的同步。由于考虑到锁的范围需要尽可能的小，所以对传参的 option 和 value 的合法性判断不需要加锁，保证锁的范围尽可能的细粒度。

Netty 加锁的地方非常多，大家在阅读代码的时候可以仔细体会下，为什么有的地方要加锁，有的地方有不需要？如果不需要，为什么？当你对锁的原理理解以后，对于这些锁的使用时机和技巧理解起来就相对容易了。

Netty 源码学习

关键类库学习

Netty 的核心类库可以分为 5 大类，需要熟练掌握：

1、ByteBuf 和相关辅助类：ByteBuf 是个 Byte 数组的缓冲区，它的基本功能应该与 JDK 的 ByteBuffer 一致，提供以下几类基本功能:

7 种 Java 基础类型、byte 数组、ByteBuffer（ByteBuf）等的读写。

缓冲区自身的 copy 和 slice 等。

设置网络字节序。

构造缓冲区实例。

操作位置指针等方法。

动态的扩展和收缩。

从内存分配的角度看，ByteBuf 可以分为两类：堆内存（HeapByteBuf）字节缓冲区：特点是内存的分配和回收速度快，可以被 JVM 自动回收；缺点就是如果进行 Socket 的 I/O 读写，需要额外做一次内存复制，将堆内存对应的缓冲区复制到内核 Channel 中，性能会有一定程度的下降。直接内存（DirectByteBuf）字节缓冲区：非堆内存，它在堆外进行内存分配，相比于堆内存，它的分配和回收速度会慢一些，但是将它写入或者从 Socket Channel 中读取时，由于少了一次内存复制，速度比堆内存快。

2、Channel 和 Unsafe：io.netty.channel.Channel 是 Netty 网络操作抽象类，它聚合了一组功能，包括但不限于网路的读、写，客户端发起连接、主动关闭连接，链路关闭，获取通信双方的网络地址等。它也包含了 Netty 框架相关的一些功能，包括获取该 Chanel 的 EventLoop，获取缓冲分配器 ByteBufAllocator 和 pipeline 等。Unsafe 是个内部接口，聚合在 Channel 中协助进行网络读写相关的操作，它提供的主要功能如下表所示：

Unsafe API 功能列表

3、ChannelPipeline 和 ChannelHandler: Netty 的 ChannelPipeline 和 ChannelHandler 机制类似于 Servlet 和 Filter 过滤器，这类拦截器实际上是职责链模式的一种变形，主要是为了方便事件的拦截和用户业务逻辑的定制。Servlet Filter 是 JEE Web 应用程序级的 Java 代码组件，它能够以声明的方式插入到 HTTP 请求响应的处理过程中，用于拦截请求和响应，以便能够查看、提取或以某种方式操作正在客户端和服务器之间交换的数据。拦截器封装了业务定制逻辑，能够实现对 Web 应用程序的预处理和事后处理。过滤器提供了一种面向对象的模块化机制，用来将公共任务封装到可插入的组件中。这些组件通过 Web 部署配置文件（web.xml）进行声明，可以方便地添加和删除过滤器，无须改动任何应用程序代码或 JSP 页面，由 Servlet 进行动态调用。通过在请求 / 响应链中使用过滤器，可以对应用程序（而不是以任何方式替代）的 Servlet 或 JSP 页面提供的核心处理进行补充，而不破坏 Servlet 或 JSP 页面的功能。由于是纯 Java 实现，所以 Servlet 过滤器具有跨平台的可重用性，使得它们很容易地被部署到任何符合 Servlet 规范的 JEE 环境中。

Netty 的 Channel 过滤器实现原理与 Servlet Filter 机制一致，它将 Channel 的数据管道抽象为 ChannelPipeline，消息在 ChannelPipeline 中流动和传递。ChannelPipeline 持有 I/O 事件拦截器 ChannelHandler 的链表，由 ChannelHandler 对 I/O 事件进行拦截和处理，可以方便地通过新增和删除 ChannelHandler 来实现不同的业务逻辑定制，不需要对已有的 ChannelHandler 进行修改，能够实现对修改封闭和对扩展的支持。ChannelPipeline 是 ChannelHandler 的容器，它负责 ChannelHandler 的管理和事件拦截与调度：

图 3 ChannelPipeline 对事件流的拦截和处理流

Netty 中的事件分为 inbound 事件和 outbound 事件。inbound 事件通常由 I/O 线程触发，例如 TCP 链路建立事件、链路关闭事件、读事件、异常通知事件等。

Outbound 事件通常是由用户主动发起的网络 I/O 操作，例如用户发起的连接操作、绑定操作、消息发送等操作。ChannelHandler 类似于 Servlet 的 Filter 过滤器，负责对 I/O 事件或者 I/O 操作进行拦截和处理，它可以选择性地拦截和处理自己感兴趣的事件，也可以透传和终止事件的传递。基于 ChannelHandler 接口，用户可以方便地进行业务逻辑定制，例如打印日志、统一封装异常信息、性能统计和消息编解码等。

4、EventLoop：Netty 的 NioEventLoop 并不是一个纯粹的 I/O 线程，它除了负责 I/O 的读写之外，还兼顾处理以下两类任务：

普通 Task：通过调用 NioEventLoop 的 execute(Runnable task) 方法实现，Netty 有很多系统 Task，创建它们的主要原因是：当 I/O 线程和用户线程同时操作网络资源时，为了防止并发操作导致的锁竞争，将用户线程的操作封装成 Task 放入消息队列中，由 I/O 线程负责执行，这样就实现了局部无锁化。

定时任务：通过调用 NioEventLoop 的 schedule(Runnable command, long delay, TimeUnit unit) 方法实现。

Netty 的线程模型并不是一成不变的，它实际取决于用户的启动参数配置。通过设置不同的启动参数，Netty 可以同时支持 Reactor 单线程模型、多线程模型和主从 Reactor 多线层模型。它的工作原理如下所示：

图 4 Netty 的线程模型

通过调整线程池的线程个数、是否共享线程池等方式，Netty 的 Reactor 线程模型可以在单线程、多线程和主从多线程间切换，这种灵活的配置方式可以最大程度地满足不同用户的个性化定制。

为了尽可能地提升性能，Netty 在很多地方进行了无锁化的设计，例如在 I/O 线程内部进行串行操作，避免多线程竞争导致的性能下降问题。表面上看，串行化设计似乎 CPU 利用率不高，并发程度不够。但是，通过调整 NIO 线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列—多个工作线程的模型性能更优。它的设计原理如下图所示：

图 5 NioEventLoop 串行执行 ChannelHandler

5、Future 和 Promise：在 Netty 中，所有的 I/O 操作都是异步的，这意味着任何 I/O 调用都会立即返回，而不是像传统 BIO 那样同步等待操作完成。异步操作会带来一个问题：调用者如何获取异步操作的结果？ChannelFuture 就是为了解决这个问题而专门设计的。下面我们一起看它的原理。ChannelFuture 有两种状态：uncompleted 和 completed。当开始一个 I/O 操作时，一个新的 ChannelFuture 被创建，此时它处于 uncompleted 状态——非失败、非成功、非取消，因为 I/O 操作此时还没有完成。一旦 I/O 操作完成，ChannelFuture 将会被设置成 completed，它的结果有如下三种可能：

操作成功。

操作失败。

操作被取消。

ChannelFuture 的状态迁移图如下所示：

图 6 ChannelFuture 状态迁移图

Promise 是可写的 Future，Future 自身并没有写操作相关的接口，Netty 通过 Promise 对 Future 进行扩展，用于设置 I/O 操作的结果，它的接口定义如下：

图 7 Netty 的 Promise 接口定义

关键流程学习

需要重点掌握 Netty 服务端和客户端的创建，以及创建过程中使用到的核心类库和 API、以及消息的发送和接收、消息的编解码。

Netty 服务端创建流程如下：

图 8 Netty 服务端创建流程

Netty 客户端创建流程如下：

图 9 Netty 客户端创建流程

Netty 项目实践

实践主要分为两类，如果项目中需要用到 Netty，则直接在项目中应用，通过实践来不断提升对 Netty 的理解和掌握。如果暂时使用不到，则可以通过学习一些开源的 RPC 或者服务框架，看这些框架是怎么集成并使用 Netty 的。以 gRPC Java 版为例，我们一起看下 gRPC 是如何使用 Netty 的。

gRPC 服务端

gRPC 通过对 Netty HTTP/2 的封装，向用户屏蔽底层 RPC 通信的协议细节，Netty HTTP/2 服务端的创建流程如下：

图 10 Netty HTTP/2 服务端创建流程

服务端 HTTP/2 消息的读写主要通过 gRPC 的 NettyServerHandler 实现，它的类继承关系如下所示：

图 11 gRPC NettyServerHandler 类继承关系

从类继承关系可以看出，NettyServerHandler 主要负责 HTTP/2 协议消息相关的处理，例如 HTTP/2 请求消息体和消息头的读取、Frame 消息的发送、Stream 状态消息的处理等，相关接口定义如下：

图 12 NettyServerHandler 处理 HTTP/2 协议消息相关接口

gRPC 客户端

gRPC 的客户端调用主要包括基于 Netty 的 HTTP/2 客户端创建、客户端负载均衡、请求消息的发送和响应接收处理四个流程,gRPC 的客户端调用总体流程如下图所示:

gRPC 的客户端调用总体流程如下图所示：

图 13 gRPC 客户端总体调用流程

gRPC 的客户端调用流程如下：

客户端 Stub(GreeterBlockingStub) 调用 sayHello(request)，发起 RPC 调用。

通过 DnsNameResolver 进行域名解析，获取服务端的地址信息（列表），随后使用默认的 LoadBalancer 策略，选择一个具体的 gRPC 服务端实例。

如果与路由选中的服务端之间没有可用的连接，则创建 NettyClientTransport 和 NettyClientHandler，发起 HTTP/2 连接。

对请求消息使用 PB（Protobuf）做序列化，通过 HTTP/2 Stream 发送给 gRPC 服务端。

接收到服务端响应之后，使用 PB（Protobuf）做反序列化。

回调 GrpcFuture 的 set(Response) 方法，唤醒阻塞的客户端调用线程，获取 RPC 响应。

需要指出的是，客户端同步阻塞 RPC 调用阻塞的是调用方线程（通常是业务线程），底层 Transport 的 I/O 线程（Netty 的 NioEventLoop）仍然是非阻塞的。

线程模型

gRPC 服务端线程模型整体上可以分为两大类：

网络通信相关的线程模型，基于 Netty4.1 的线程模型实现。

服务接口调用线程模型，基于 JDK 线程池实现。

gRPC 服务端线程模型和交互图如下所示：

图 14 gRPC 服务端线程模型

其中，HTTP/2 服务端创建、HTTP/2 请求消息的接入和响应发送都由 Netty 负责，gRPC 消息的序列化和反序列化、以及应用服务接口的调用由 gRPC 的 SerializingExecutor 线程池负责。

gRPC 客户端的线程主要分为三类：

业务调用线程

客户端连接和 I/O 读写线程

请求消息业务处理和响应回调线程

gRPC 客户端线程模型工作原理如下图所示（同步阻塞调用为例）：

图 15 客户端调用线程模型

客户端调用主要涉及的线程包括：

应用线程，负责调用 gRPC 服务端并获取响应，其中请求消息的序列化由该线程负责。

客户端负载均衡以及 Netty Client 创建，由 grpc-default-executor 线程池负责。

HTTP/2 客户端链路创建、网络 I/O 数据的读写，由 Netty NioEventLoop 线程负责。

响应消息的反序列化由 SerializingExecutor 负责，与服务端不同的是，客户端使用的是 ThreadlessExecutor，并非 JDK 线程池。

SerializingExecutor 通过调用 responseFuture 的 set(value)，唤醒阻塞的应用线程，完成一次 RPC 调用。

gRPC 采用的是网络 I/O 线程和业务调用线程分离的策略，大部分场景下该策略是最优的。但是，对于那些接口逻辑非常简单，执行时间很短，不需要与外部网元交互、访问数据库和磁盘，也不需要等待其它资源的，则建议接口调用直接在 Netty /O 线程中执行，不需要再投递到后端的服务线程池。避免线程上下文切换，同时也消除了线程并发问题。

例如提供配置项或者接口，系统默认将消息投递到后端服务调度线程，但是也支持短路策略，直接在 Netty 的 NioEventLoop 中执行消息的序列化和反序列化、以及服务接口调用。

减少锁竞争优化：当前 gRPC 的线程切换策略如下：

图 16 gRPC 线程锁竞争

优化之后的 gRPC 线程切换策略：

图 17 gRPC 线程锁竞争优化

通过线程绑定技术（例如采用一致性 hash 做映射）, 将 Netty 的 I/O 线程与后端的服务调度线程做绑定，1 个 I/O 线程绑定一个或者多个服务调用线程，降低锁竞争，提升性能。

Netty 故障定位技巧

尽管 Netty 应用广泛，非常成熟，但是由于对 Netty 底层机制不太了解，用户在实际使用中还是会经常遇到各种问题，大部分问题都是业务使用不当导致的。Netty 使用者需要学习 Netty 的故障定位技巧，以便出了问题能够独立、快速的解决。‘’

接收不到消息

如果业务的 ChannelHandler 接收不到消息，可能的原因如下：

业务的解码 ChannelHandler 存在 BUG，导致消息解码失败，没有投递到后端。

业务发送的是畸形或者错误码流（例如长度错误），导致业务解码 ChannelHandler 无法正确解码出业务消息。

业务 ChannelHandler 执行了一些耗时或者阻塞操作，导致 Netty 的 NioEventLoop 被挂住，无法读取消息。

执行业务 ChannelHandler 的线程池队列积压，导致新接收的消息在排队，没有得到及时处理。

对方确实没有发送消息。

定位策略如下：

在业务的首个 ChannelHandler 的 channelRead 方法中打断点调试，看是否读取到消息。

在 ChannelHandler 中添加 LoggingHandler，打印接口日志。

查看 NioEventLoop 线程状态，看是否发生了阻塞。

通过 tcpdump 抓包看消息是否发送成功。

内存泄漏

通过 jmap -dump:format=b,file=xx pid 命令 Dump 内存堆栈，然后使用 MemoryAnalyzer 工具对内存占用进行分析，查找内存泄漏点，然后结合代码进行分析，定位内存泄漏的具体原因，示例如下所示：

图 18 通过 MemoryAnalyzer 工具分析内存堆栈

性能问题

如果出现性能问题，首先需要确认是 Netty 问题还是业务问题，通过 jstack 命令或者 jvisualvm 工具打印线程堆栈，按照线程 CPU 使用率进行排序（top -Hp 命令采集），看线程在忙什么。通常如果采集几次都发现 Netty 的 NIO 线程堆栈停留在 select 操作上，说明 I/O 比较空闲，性能瓶颈不在 Netty，需要继续分析看是否是后端的业务处理线程存在性能瓶颈:

图 19 Netty NIO 线程运行堆栈

如果发现性能瓶颈在网络 I/O 读写上，可以适当调大 NioEventLoopGroup 中的 work I/O 线程数，直到 I/O 处理性能能够满足业务需求。

读者福利：

本人这边专门整理了一套对应的Java面经pdf文档复习资料，含全面的java知识点面试题，还有其他各类知识点的整理，特别适合一些即将面试或准备跳槽的Java开发者查缺补漏，需要获取这套文档资料的读者朋友们企鹅群（865642868）