新版的dubbo-admin 在支持dubbo2.7新特性的同時(shí)榄审，還兼容dubbo2.6砌们。基于dubbo2.7的元數(shù)據(jù)中心瘟判，我們可以做一些事情怨绣，比如服務(wù)測(cè)試角溃，在目前版本的dubbo-admin中拷获，其實(shí)已經(jīng)支持這個(gè)功能。
結(jié)論
先說(shuō)結(jié)論减细，導(dǎo)致內(nèi)存泄漏的代碼在 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);
}
簡(jiǎn)單來(lái)說(shuō)就是 URL_IDS_MAPPER一直在增長(zhǎng)，導(dǎo)致它占用的內(nèi)存越來(lái)越越大，最后導(dǎo)致不停的fullGC
分析
什么情況下會(huì)執(zhí)行這個(gè)方法驮吱？
當(dāng)/dubbo下的節(jié)點(diǎn)發(fā)生變更的時(shí)候URL_IDS_MAPPER的本意只是想維護(hù)一個(gè) md5 與 fullUrl 的關(guān)系茧妒，但因?yàn)榭刂撇划?dāng)，導(dǎo)致它的容量不斷增長(zhǎng)左冬，感覺(jué)這個(gè)URL_IDS_MAPPER完全沒(méi)有必要控制不當(dāng)指的是什么桐筏？
比如每次提供者或者消費(fèi)者 上線 -> 下線 -> 上線，雖然該服務(wù)一直都只有一個(gè)實(shí)例拇砰，但卻產(chǎn)生了多個(gè)MD5梅忌，如果頻繁的進(jìn)行這個(gè)操作，就會(huì)導(dǎo)致URL_IDS_MAPPER容量越來(lái)越大與
URL_IDS_MAPPER對(duì)應(yīng)的其實(shí)還有一個(gè) 'registryCache'除破，但為什么 'registryCache'沒(méi)有內(nèi)存泄漏問(wèn)題牧氮？
因?yàn)樵谠摲椒ㄖ杏嗅槍?duì)'registryCache'的清除操作怎么發(fā)現(xiàn)的這個(gè)問(wèn)題？
如果服務(wù)量比較小瑰枫，服務(wù)變更不頻繁踱葛，可能感知不到這個(gè)問(wèn)題。但如果服務(wù)量大又經(jīng)常上下線光坝，這個(gè)問(wèn)題就很明顯了尸诽。會(huì)發(fā)現(xiàn)應(yīng)用占用的內(nèi)存越來(lái)大，到后面服務(wù)器就一直在fullGC了怎么排查盯另？
top -> 看GC -> 內(nèi)存dump -> MAT分析 -> 查看大對(duì)象 -> 發(fā)現(xiàn)URL_IDS_MAPPER中元素有100萬(wàn)+ ->再分析代碼
