分析結論
接口無法連接 dubbo 註冊中心，會不斷重試，觸發 dubbo(當前版 本:dubbo-2.5.4-SNAPSHOT-jdk1.6-8.4.jar)內存泄露 bug，導致 jvm 內存逐漸耗光， 最終內存溢出。
說明:由於沒有 dubbo 相關的源碼，無法準確定位 dubbo 內存泄露原因，以上結論僅從數據 的相關性分析得出。
現象描述
2019年9月26日晚上，將接口從Provision-Interface裏面剝離出來，單獨部署在134.XXX.XXX.11，134.XXX.XXX.12，134.XXX.XXX.13，134.XXX.XXX.215，134.XXX.XXX.216，134.XXX.XXX.217這6臺服務器上，當晚服務部署完畢，選址功能測試正常。
| 時間點 | 描述 | 備註 |
|---|---|---|
| 2019.10.09 8:50 | 運維羣收到用戶選址系統無法選址的反饋 | |
| 2019.10.09 8:55 | 檢查OMC上選址接口服務 | |
| 2019.10.09 9:00 | 選址接口服務異常，重啓OMC上選址接口服務 | |
| 2019.10.09 9:05 | 確認問題恢復，羣通知客戶，客戶確認系統使用恢復正常 |
初步分析了服務運行日誌，10月9日上午7點左右有大量的FULL GC日誌，其中服務異常時間段內的FULL GC特別頻繁，1分鐘內有50秒在執行FULL GC，而且每次FULL GC能回收的內存非常少。因爲內存被消耗完，最終導致服務異常，無法提供正常的選址功能。
現場分析
現場對接口服務進行了內存監控，發現接口服務的內存呈現一個上升趨勢
10月9日18:00內存採樣
10月9日21:00內存採樣
10月10日7:00內存採樣
結合服務器運行日誌，初步判斷是內存泄漏導致服務異常。
分析過程
從 9 月 26 日到 10 月 9 日的服務器日誌文件(catalina.out.2)分析發現，存在大量(共 98075 次)的 TimeoutException 異常，如下圖
所示:
經分析確認，這部分異常是由於嘗試連接 dubbo 註冊中心失敗導致的，由於無法連接註冊 中心，dubbo 會不斷重試。如下圖所示：
同時，從服務器日誌文件(catalina.out.2)中發現，9 月 30 日開始頻繁出現“Full GC”信息:
同時，從服務器日誌文件(catalina.out.2)中發現，9 月 30 日開始頻繁出現“Full GC”信息:
10 月 16 日 14:00 從服務 134.XXX.XXX.13 節點獲取了實時內存 dump 文件 heap.bin 進行進 一步分析，發現 com.alibaba.dubbo.common.URL 創建了 685,963 個實例，佔用了約 70%的內 存(1,409,556,408/2,032,436,144=69.35%)
這部分 com.alibaba.dubbo.common.URL 對象絕大部分被 3 個線程引用: DubboClientReconnectTimer-thread-2 DubboRegistryFailedRetryTimer-thread-1 DubboClientHandler-134.XXX.XXX.149:8001-thread-120 從名稱推斷，這些線程和連接失敗重試有關。
從對 134.XXX.XXX.13 節點的監控來看 com.alibaba.dubbo.common.URL 實例數一直持續增長:
分析工具
Jdk 工具包 jmap jstackEclipseMAT或jvisualvm
重點說明：故障發生時可以在重啓服務前通過以下命令保存現場，以方便事後分析！！！
0.獲取進程pid netstat -anp|grep [port] 或者 ps -ef|grep [appname]
通過端口get pid：
通過appname get pid：
1.導出虛擬機線程信息:jstack <pid>
2.導出虛擬機內存 dump:jmap -dump:live,format=b,file=heap.bin <pid>
3.根據類查看實例數:jmap -histo <pid>
4.保存服務器運行日誌
例如：tomcat一般備份./logs/下面日誌文件 catalina.out 如果日誌有重定向按實際路徑備份
5.保留業務系統報錯截圖或操作步驟