Netty故障排查技巧

1. 接收不到消息

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

 

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

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

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

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

5）对方确实没有发送消息。

 

定位策略如下：

 

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

2）在 ChannelHandler 中添加 LoggingHandler，打印接口日志；

3）查看 NioEventLoop 线程状态，看是否发生了阻塞；

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

1. 内存泄露

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

1. 性能问题

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

 

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

 

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