记一次内存泄漏排查过程

新版的dubbo-admin 在支持dubbo2.7新特性的同时，还兼容dubbo2.6。基于dubbo2.7的元数据中心，我们可以做一些事情，比如服务测试，在目前版本的dubbo-admin中，其实已经支持这个功能。

结论

先说结论，导致内存泄漏的代码在 org.apache.dubbo.admin.service.RegistryServerSync#notify 中，核心代码就是这一段

if (URL_IDS_MAPPER.containsKey(url.toFullString())) {
    ids.put(URL_IDS_MAPPER.get(url.toFullString()), url);
} else {
    String md5 = CoderUtil.MD5_16bit(url.toFullString());
    ids.put(md5, url);
    URL_IDS_MAPPER.putIfAbsent(url.toFullString(), md5);
}

简单来说就是 URL_IDS_MAPPER一直在增长，导致它占用的内存越来越越大，最后导致不停的fullGC

分析

1. 什么情况下会执行这个方法？
   当/dubbo下的节点发生变更的时候

2. URL_IDS_MAPPER的本意只是想维护一个 md5 与 fullUrl 的关系，但因为控制不当，导致它的容量不断增长，感觉这个URL_IDS_MAPPER完全没有必要

3. 控制不当指的是什么？
   比如每次提供者或者消费者 上线 -> 下线 -> 上线，虽然该服务一直都只有一个实例，但却产生了多个MD5，如果频繁的进行这个操作，就会导致URL_IDS_MAPPER容量越来越大

4. 与URL_IDS_MAPPER对应的其实还有一个 'registryCache'，但为什么 'registryCache'没有内存泄漏问题？
   因为在该方法中有针对'registryCache'的清除操作

5. 怎么发现的这个问题？
   如果服务量比较小，服务变更不频繁，可能感知不到这个问题。但如果服务量大又经常上下线，这个问题就很明显了。会发现应用占用的内存越来大，到后面服务器就一直在fullGC了

6. 怎么排查？
   top -> 看GC -> 内存dump -> MAT分析 -> 查看大对象 -> 发现URL_IDS_MAPPER中元素有100万+ ->再分析代码