一次漫长的dubbo网关内存泄露排查经历

背景介绍

在微服务架构中，不同的微服务有不同的网络地址，而客户端则是通过统一的地址进行调用，在客户端与服务端之间需要有一个通信的桥梁，这就产生了微服务网关。微服务网关可以连接客户端与微服务，提供统一的认证方式，管理接口的生命周期，做更好的负载均衡、熔断限流，提供方便的监控，提供统一的风控入口。

今天要介绍的主角是dubbo微服务网关，来自公司内部自研的提供http协议到dubbo协议转换的微服务网关，跟本文相关的就是它的核心点：dubbo泛化调用。dubbo官网对泛化调用的描述为

“泛化接口调用方式主要用于客户端没有 API 接口及模型类元的情况，参数及返回值中的所有 POJO 均用map表示，通常用于框架集成。“

dubbo最常见的调用方式是引入服务提供方定义的jar包，用于描述接口，但如果是网关引入所有的dubbo提供者的jar包就很不现实，况且如果需要新增接口就需要重新发布网关，所以需要使用泛化调用来解决这个问题，官网提供的示例代码截图如下：

问题描述

这款网关上线以来一直运行稳定，直到某一天出现了问题，频繁full GC，cpu上涨，错误率飙升，然而接口的调用量并没有上涨。立马重启机器，并且保留了一份内存dump文件，分析了一周没有结论，最近又出现了一次，情形类似。

full gc频繁

old区被填满

cpu上涨，错误率上升

问题排查

• 从内存dump文件查起

从监控上基本能断定是内存问题，那就分析一下当初dump出来的内存文件，使用eclipse的mat插件分析

RegistryDirectory对象多达7000多个，直接定位为RegistryDirectory可能存在内存泄露。再跟进一下这个对象的持有者

发现是com.alibaba.dubbo.remoting.zookeeper.curator.CuratorZookeeperClient$CuratorWatcherImpl，搜索一下该类的对象

这个对象也非常多。到这里就去查看dubbo的源码（本文dubbo源码基于2.6.6）。首先查找com.alibaba.dubbo.remoting.zookeeper.curator.CuratorZookeeperClient$CuratorWatcherImpl创建的地方

只有一个地方创建，接着跟进addChildListener

只有在订阅zookeeper的节点时会调用，继续查找订阅zookeeper的地方，发现有两处

• 一处是ReferenceConfig的createProxy会调用RegistryProtocol的doRefer，进而订阅zookeeper；
• 另一处是FailbackRegistry中会有一个线程不停地对订阅失败的path进行重试，在zk重新连接时会recover。

首先怀疑第二处

dubbo应用在与zookeeper断开连接重新连上的时候会recover，recover里面执行的就是重新订阅zookeeper。这很好模拟，线下打断点测试一下在zookeeper端开重连的时候是否会重新生成CuratorWatcherImpl对象。结果当然是没有生成，因为dubbo应用会缓存CuratorWatcherImpl对象，对于相同的URL订阅，返回的都是相同的CuratorWatcherImpl对象，并不会重新生成。

• 从网络寻求答案

换个思路重新开始，去网上看看又没人遇到相同的问题，网上搜了一下，发现了 https://github.com/apache/dubbo/issues/376 跟我的问题几乎一样，难道是发布导致的问题？但经过几次对比否决了，因为平时发布都没事，偏偏这时候出事？而且两次爆发时网卡流量并不高。

否决了这个issue后又发现了一个issue， https://github.com/apache/dubbo/issues/4587

但这个很快又被否决了，因为这里他的主要问题是reference未缓存，在dubbo的文档中针对这个是有提及的

出问题的dubbo网关是对reference做了缓存（以interface+version+group+timeout作为key，timeout是为了能动态调整接口的超时时间），理论上不会重复生成reference

• “守株待兔“

问题真的陷入僵局，好在看到了这么一篇文章，《netty堆外内存泄露排查盛宴》（点击原文查看），作者在面对无法排查的问题时，在线上植入一段监控代码来协助定位问题。于是在想能不能也植入一段代码，看看这么多订阅到底是什么。通过对dubbo的源码翻看，找到这么一个可以获取订阅的点

ZookeeperRegistry中有个zkListeners存储了订阅了哪些URL，如果能检测这个字段是不是就可以了？简单点，定时检测并打印日志。通过反射来获取这个变量

代码改好，测试一下，放到线上一台机器守株待兔。经过一下午，终于抓到了

发现其中一个service，被重复订阅了很多次，而且订阅的URL只有timestamp不一样，且只有一个服务会这样，怀疑跟服务本身有关，查看该服务，发现其没有provider

难道没有provider的服务会出现重复订阅？线下复现试试，使用网关去调用一个没有provider的服务（省略复现过程），果然问题出现了！问题能复现就很好排查了，打断点根据调用栈就能找到订阅的地方

在生成referenceConfig时会初始化proxy，如果初始化过就会忽略，问题就在createProxy

如果check=true，且provider不存在，createProxy就会抛异常，createProxy底层去订阅了zookeeper，缓存了RegistryDirectory对象，如果不停订阅，内存就会被撑爆，看下这个报错在那几天是否很多

好像也不是很多，单机加起来几百次，为什么会产生这么多RegistryDirectory对象，通过调试发现

每次订阅的URL是生成的，也就是timestamp不同，且会被塞入urls这个变量缓存起来，然后循环这个urls进行refer（即订阅），也就是说第一次urls中有1个URL需要订阅，第二次就成了2，第三次是3，也就是高斯计算的那个1+2+3+4+...+100的问题，请求100次会产生5050个RegistryDirectory对象。

解决办法很简单，将check=true改为check=false。

总结

• 这个是dubbo的bug，在2.7.5版本中已经将订阅的URL中的timestamp去掉了，只会对一个URL订阅一次，issue即之前提到的https://github.com/apache/dubbo/issues/4587，但当时这个issue并没有解决我们的疑问；

• 泛化调用时将reference的check设置为false，否则可能会出现内存泄露；普通调用（xml配置）则无影响，因为check=true如果没有provider应用会启动失败；

• 问题排查难易程度：通过监控、代码、日志直接定位的问题 < 可稳定复现的问题 < 不可稳定复现的问题（偶尔出现） < 不可复现的问题（只出现一次），本文的问题属于不可稳定复现的问题。

• ---