Netty网络编程第九卷

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

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

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

Netty 服务端创建流程如下：

Netty 客户端创建流程如下：

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

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

1）业务的解码 ChannelHandler 存在 BUG，导致消息解码失败，没有投递到后端；
2）业务发送的是畸形或者错误码流（例如长度错误），导致业务解码 ChannelHandler 无法正确解码出业务消息；
3）业务 ChannelHandler 执行了一些耗时或者阻塞 *** 作，导致 Netty 的 NioEventLoop 被挂住，无法读取消息；
4）执行业务 ChannelHandler 的线程池队列积压，导致新接收的消息在排队，没有得到及时处理；
5）对方确实没有发送消息。

定位策略如下：

1）在业务的首个 ChannelHandler 的 channelRead 方法中打断点调试，看是否读取到消息；
2）在 ChannelHandler 中添加 LoggingHandler，打印接口日志；
3）查看 NioEventLoop 线程状态，看是否发生了阻塞；
4）通过 tcpdump 抓包看消息是否发送成功。

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

示例如下所示：

如果出现性能问题，首先需要确认是 Netty 问题还是业务问题，通过 jstack 命令或者 jvisualvm 工具打印线程堆栈，按照线程 CPU 使用率进行排序（top -Hp 命令采集），看线程在忙什么。

通常如果采集几次都发现 Netty 的 NIO 线程堆栈停留在 select *** 作上，说明 I/O 比较空闲，性能瓶颈不在 Netty，需要继续分析看是否是后端的业务处理线程存在性能瓶颈。

如下图所示：

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

这里不展开讲了，推荐先看一下下面这篇文章，然后再去看github上面的Jupiter分布式RPC框架源码

一起学Netty（十四）之 Netty生产级的心跳和重连机制

fengjiachun/Jupiter

京东到家基于netty与websocket的实践

长连接网关技术专题(一)：京东京麦的生产级TCP网关技术实践总结

跟着源码学IM(十)：基于Netty，搭建高性能IM集群（含技术思路+源码）

绝对干货：基于Netty实现海量接入的推送服务技术要点

史上最强Java NIO入门：担心从入门到放弃的，请读这篇！

Netty in Action实战精髓