檢視當時的full gc從圖上面看已經很頻繁
列印dump檔案 執行命令：jmap -dump:format=b,file=/export/logs/anycall.jd.local/heapdump.bin 然後通過eclipse memory analyzer檢視，如下圖，2.9g 佔據了大部分，我們最主要的是看到底哪些類撐爆了記憶體，
繼續往下走，檢視dominator_tree，如下圖：可以看到藍色陰影部分，是在errror日誌列印的時候輸出的內容。
這部分問什麼會造成記憶體**的問題呢，看下面這個**，問題根源找到，當呼叫對方介面，返回大量錯誤的時候，不斷的在+操作，而且每次的字串都是不同的，則建立了大量的新的物件。
loghelper.send_message_log.error("sendpostrequest 傳送訊息返回失敗，clientcode：" + clientcode + "，返回碼：" + resultcode + "，訊息：" + msgjson);
當時沒有可用率報警，是因為，業務上面返回1表示成功，返回0表示對方接受處理錯誤，業務**並沒有丟擲異常。ump的異常新增到了catch裡面了。
還有一些其它我們的業務日誌如果有大量輸出的時候，也要注意。
乙個記憶體洩漏問題的排查
監控的mem一直居高不下 使用jstat命令檢視gc的情況，發現ygc已經停止，一直在fgc，懷疑記憶體已經洩漏，堆記憶體中有大量無法 的物件。然後檢視gc日誌，發現年輕代和老年代使用率達到99 且full gc後記憶體沒有被 確定肯定是有物件無法被 需要解密的資料 這是加解密的功能，每次執行加解密...
乙個詭異的C 記憶體洩露問題。
delet被編譯成了兩個步驟 調相應析構函式，p指向的記憶體塊 即使父類沒宣告虛析構函式，第二步還是生效的，所以你derived的記憶體區是被正確 的，但derived的記憶體區域 std string 並不是連續區間，可能是這樣的東東 64byte ptr delet的第二步 的就只是這 64by...
乙個C語言典型的記憶體洩露問題
具體的問題見下面的demo include void getheap int p p是null的位址 形式引數int p在棧空間內，函式結束後就釋放了，malloc分配的空間也丟失了，同樣也沒有帶回實參 int main 執行 原因 改正如下 include void getheap int p p...