背景 在阿里雲上看到我運行了一段時間的程序，發現 memory 一項基本是在穩步提升，就知道有內存泄漏的情況出現。如下圖 近三日從 35% 升到 40%，緩慢而堅定的提升。 代碼 排查此問題需要分析其堆內存快照，當然我們不能直接使用線上機器調試。不幸的是測服機器在內網，和阿里雲聯不通 ...

1、發現服務器變的特別卡，正常服務運行很慢。 到服務器上查詢一番發現top下發現 bashd的進程占用100%CPU了。 find /-name bashd* ...

online的環境中發現有一個java進程內存占用一直增大，xmx設置的6144m 但是用top -p 查詢占用了8.9G內存，上次用jmap查看堆內存只有3個多G 應該繼續排查一下堆外內存可能存在的內存泄漏問題。 [root@localhost logs]# top -p 755 ...

有個java程序越跑越慢，如何排查？ 首先通過jps找到java進程ID。然后top -p [pid]發現內存占用達到了最大值（-Xmx）。開始懷疑是由於頻繁Full GC導致的，於是通過jstat -gcutil [pid] 60000查看GC的情況，其中60000表示每隔1分鍾輸出一次 ...

什么是內存泄漏 內存泄漏是指java應用的堆內存使用率持續升高，直至內存溢出。 內存泄漏的的原因可能有多種 分配給應用程序的內存本身過小。而應用的業務代碼，確實需要生成大量的對象 代碼bug，某些需要被回收的對象，由於代碼bug，卻持續的被引用，導致java虛擬機無法回收這些對象 ...

沒有經驗的程序員經常認為Java的自動垃圾回收完全使他們免於擔心內存管理。這是一個常見的誤解：雖然垃圾收集器做得很好，但即使是最好的程序員也完全有可能成為嚴重破壞內存泄漏的犧牲品。讓我解釋一下。 當不必要地維護不再需要的對象引用時，會發生內存泄漏。這些泄漏很糟糕。首先，當程序消耗越來越多 ...

由來 前些日子小組內安排值班，輪流看顧我們的服務，主要做一些報警郵件處理、Bug 排查、運營 issue 處理的事。工作日還好，無論干什么都要上班的，若是輪到周末，那這一天算是毀了。 不知道是公司網絡廣了就這樣還是網絡運維組不給力，網絡總有問題，不是這邊交換機脫網了就是那邊路由器壞了 ...

使用MAT工具排查內存泄漏的問題 一.概要說明 使用 Memory Analyzer 來分析生產環境的 Java 堆轉儲文件，可以從數以百萬計的對象中快速計算出對象的 Retained Size，查看是誰在阻止垃圾回收，並自動生成一個 Leak Suspect（內存泄露可疑點）報表 ...