jdk17下netty导致堆内存疯涨原因排查

  天网风控灵玑系统是基于内存计算实现的高吞吐低延迟在线计算服务，提供滑动或滚动窗口内的 count、distinctCout、max、min、avg、sum、std 及区间分布类的在线统计计算服务。客户端和服务端底层通过 netty 直接进行 tcp，且服务端也是基于 netty 将数据备份到对应的 slave 集群。

  灵玑第 1 个版本经过大量优化，系统能提供较大的吞吐量。如果对客户端设置 10ms 超时，服务端 1wqps/core 的流量下，可用率只能保证在 98.9% 左右，高并发情况下主要是 gc 导致可用率降低。如果基于 cms 垃圾回收器。当一台 8c16g 的机器在经过第二个版本优化后吞吐量超过 20wqps 的时候，那么大概每 4 秒会产生一次 gc。如果按照一次 gc 等于 30ms。那么至少分钟颗粒度在 gc 时间的占比至少在 (15*30/1000/60)=0.0075。也就意味着分钟级别的 tp992 至少在 30ms。不满足相关业务的需求。

  为了解决上述延迟过高的有关问题，JDK 11 开始推出了一种低延迟垃圾回收器 ZGC。ZGC 使用了一些新技术和优化算法，可以将 GC 暂停时间控制在 10 毫秒以内，而在 JDK 17 的加持下，ZGC 的暂停时间还可以控制在亚毫秒级别。实测在平均停顿时间在 10us 左右，主要是基于一个染色指针和读屏障做到大多数 gc 阶段能做到并发的，有兴趣的同学能了解下，并且 jdk17 是一个 lts 版本。

  采用 jdk17+zgc 经过相关的压测后，一切都在向着好的方向发展，但是在一种特殊场景压测，需要将数据从北京数据中心同步给宿迁数据中心的时候，发现了一些诡异的事情

  第一反应是遇到内存疯涨和无法释放该问题时，首先归纳为内存泄漏问题，感觉这题也简单明了。开始相关内存泄漏检查：先 dump 堆内存分析发现占用堆内存的是 netty 相关的对象，恰好前段时间也有个同学也分享了 netty 下的不合理使用 netty byBuf 导致的内存泄漏，进一步增加了对 netty 内存泄露的怀疑。于是开启 netty 内存泄漏严格检查模式 （加上 jvmon.level=PARANOID），重新试跑并未曾发现相关内存泄漏日志。好吧～！初步判定不是 netty 内存泄漏。

  会不会是 netty 与 jdk17 兼容不好导致的 bug? 回滚 jdk8 测试发现的确不存在这样的一个问题，当时使用的是 jdk17.0.7 版本。正好官方发布了 jdk17.0.8 版本，并且看到版本介绍上有若干的 Bug Fixes。所以又升级了 jdk 一个小版本，然而察觉缺陷仍然在。会不会是 netty 的版本过低？正好看见 gitup 上也有类似的 issue# 并且在高版本疑似修复了该问题，修改了 netty 几个版本重新压测，然而察觉缺陷仍然在。

  经过上述两次排查，察觉缺陷比想象中复杂，应该深入分析下为什么，重新梳理了下相关线索：

  发现回滚至 jdk8 的时候，对应宿迁中心的集群接受到的备份数据量比北京中心发送的数据量低了很多

  为什么没有流量了还一直有 gc，cpu 高应该是 gc 造成的（当时认为是 zgc 的内存的一些特性）

  分析过后已经有了基本的猜想，因为跨数据中心下机房延迟更大，单 channel 信道下已经没法满足同步数据能力，导致 netty 的 eventLoop 的消费能不足导致积压。 解决方案：增加与备份数据节点的 channel 信道连接，采用 connectionPool，每次批量同步数据的时候随机选择一个存活的 channel 进行数据通信。经过相关改造后察觉缺陷得到了解决。

  虽然经过上述的改造，表面上看似解决了问题，但是问题的最终的原因还是没有被发现

  1. 如果是 eventLoop 消费能力不够，为什么停止压测后，相关内存只是缓慢减少，按理说应该是疯狂的内存减少。

  2. 为什么一直 cpu 在 23% 左右，按照平时的压测数据，同步数据是一个流转批的操作，最多也就消耗 5% cpu 左右，多出来的 cpu 应该是 gc 造成的，但是数据同步应该并不多，不应该造成这么多的 gc 压力。

  推测应该是有个 netty eventLoop 消费耗时阻塞的操作导致消费能力大幅度下降。所以感觉还是 netty 的问题，于是开了 netty 的相关 debug 日志。发现了一行关键日志

  所以最最终的原因：如果这样一个时间段我们的 netty 的消费者 EventLoop 处理消费因为申请直接内存在达到最大内存的场景，那么就会导致有大量的任务消费都会同步去等待申请直接内存上。并且如果只有少数的的直接内存，那么就会成为大面积的消费阻塞。

  经过上述的源码分析，已经看到了最终的原因，就是 ByteBuffer.allocateDirect gc 同步等待直接内存释放导致消费能力严重不足导致的，并且在最大直接内存不足的情况下，大面积的消费阻塞耗时在申请直接内存，导致消费 WriteTask 能力接近于 0，内存从而无法下降

  同步数据的时候调用 writeAndFlush 应该加上相关的异常（以下代码 2），若果能提前感知到异常 OutOfMemoryError 那么更方便排查到相关问题。

  jdk17 下监控系统看到的非堆内存监控并未与系统实际使用的直接内存统计一致，导致开始定位问题无法定位到直接内存已达到最大值，从而并未往这个方案思考。

  相关引用的中间件底层通信也是依赖于 netty 通信，如果有类似的数据同步也有一定可能会触发类似的问题。特别 ump 在高版本和 titan 使用 netty 的时候是进行了 shade 打包的，并且相关的 jvm 参数也被修改，虽然不会触发该 bug，但是也可能会引起触发系统 gc。