总结分享：一次漫长的dubbo网关内存泄露排查经历

背景介绍

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

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

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

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

问题描述

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

问题排查

• 从内存dump文件查起

从监控上基本能断定是内存问题&#x