1、爲什麼會發生內存泄漏
java 如何檢測內在泄漏呢？我們需要一些工具進行檢測，並發現內存泄漏問題，不然很容易發生down機問題。
編寫java程序最爲方便的地方就是我們不需要管理內存的分配和釋放，一切由jvm來進行處理，當java對象不再被應用時，等到堆內存不夠用時，jvm會進行垃圾回收，清除這些對象佔用的堆內存空間，如果對象一直被應用，jvm無法對其進行回收，創建新的對象時，無法從Heap中獲取足夠的內存分配給對象，這時候就會導致內存溢出。而出現內存泄露的地方，一般是不斷的往容器中存放對象，而容器沒有相應的大小限制或清除機制。容易導致內存溢出。
當服務器應用佔用了過多內存的時候，如何快速定位問題呢？現在，Eclipse MAT的出現使這個問題變得非常簡單。EclipseMAT是著名的SAP公司貢獻的一個工具，可以在Eclipse網站下載到它，完全免費的。
要定位問題，首先你需要獲取服務器jvm某刻內存快照。jdk自帶的jmap可以獲取內存某一時刻的快照，導出爲dmp文件後，就可以用Eclipse MAT來分析了，找出是那個對象使用內存過多。
2、內存泄漏的現象：
常常地，程序內存泄漏的最初跡象發生在出錯之後，在你的程序中得到一個OutOfMemoryError。這種典型的情況發生在產品環境中，而在那裏，你希望內存泄漏儘可能的少，調試的可能性也達到最小。也許你的測試環境和產品的系統環境不盡相同，導致泄露的只會在產品中暴露。這種情況下，你需要一個低負荷的工具來監聽和尋找內存泄漏。同時，你還需要把這個工具同你的系統聯繫起來，而不需要重新啓動他或者機械化你的代碼。也許更重要的是，當你做分析的時候，你需要能夠同工具分離而使得系統不會受到干擾。
一個OutOfMemoryError常常是內存泄漏的一個標誌，有可能應用程序的確用了太多的內存；這個時候，你既不能增加JVM的堆的數量，也不能改變你的程序而使得他減少內存使用。但是，在大多數情況下，一個OutOfMemoryError是內存泄漏的標誌。一個解決辦法就是繼續監聽GC的活動，看看隨時間的流逝，內存使用量是否會增加，如果有，程序中一定存在內存泄漏。
3、發現內存泄漏
1. jstat -gc pid
可以顯示gc的信息，查看gc的次數，及時間。
其中最後五項，分別是young gc的次數，young gc的時間，full gc的次數，full gc的時間，gc的總時間。
2.jstat -gccapacity pid
可以顯示，VM內存中三代（young,old,perm）對象的使用和佔用大小，
如：PGCMN顯示的是最小perm的內存使用量，PGCMX顯示的是perm的內存最大使用量，
PGC是當前新生成的perm內存佔用量，PC是但前perm內存佔用量。
其他的可以根據這個類推， OC是old內純的佔用量。
3.jstat -gcutil pid
統計gc信息統計。
4.jstat -gcnew pid
年輕代對象的信息。
5.jstat -gcnewcapacity pid
年輕代對象的信息及其佔用量。
6.jstat -gcold pid
old代對象的信息。
7.stat -gcoldcapacity pid
old代對象的信息及其佔用量。
8.jstat -gcpermcapacity pid
perm對象的信息及其佔用量。
9.jstat -class pid
顯示加載class的數量，及所佔空間等信息。
10.jstat -compiler pid
顯示VM實時編譯的數量等信息。
11.stat -printcompilation pid
當前VM執行的信息。
一些術語的中文解釋：
S0C：年輕代中第一個survivor（倖存區）的容量 (字節)
S1C：年輕代中第二個survivor（倖存區）的容量 (字節)
S0U：年輕代中第一個survivor（倖存區）目前已使用空間 (字節)
S1U：年輕代中第二個survivor（倖存區）目前已使用空間 (字節)
EC：年輕代中Eden（伊甸園）的容量 (字節)
EU：年輕代中Eden（伊甸園）目前已使用空間 (字節)
OC：Old代的容量 (字節)
OU：Old代目前已使用空間 (字節)
PC：Perm(持久代)的容量 (字節)
PU：Perm(持久代)目前已使用空間 (字節)
YGC：從應用程序啓動到採樣時年輕代中gc次數
YGCT：從應用程序啓動到採樣時年輕代中gc所用時間(s)
FGC：從應用程序啓動到採樣時old代(全gc)gc次數
FGCT：從應用程序啓動到採樣時old代(全gc)gc所用時間(s)
GCT：從應用程序啓動到採樣時gc用的總時間(s)
NGCMN：年輕代(young)中初始化(最小)的大小 (字節)
NGCMX：年輕代(young)的最大容量 (字節)
NGC：年輕代(young)中當前的容量 (字節)
OGCMN：old代中初始化(最小)的大小 (字節)
OGCMX：old代的最大容量 (字節)
OGC：old代當前新生成的容量 (字節)
PGCMN：perm代中初始化(最小)的大小 (字節)
PGCMX：perm代的最大容量 (字節)
PGC：perm代當前新生成的容量 (字節)
S0：年輕代中第一個survivor（倖存區）已使用的佔當前容量百分比
S1：年輕代中第二個survivor（倖存區）已使用的佔當前容量百分比
E：年輕代中Eden（伊甸園）已使用的佔當前容量百分比
O：old代已使用的佔當前容量百分比
P：perm代已使用的佔當前容量百分比
S0CMX：年輕代中第一個survivor（倖存區）的最大容量 (字節)
S1CMX ：年輕代中第二個survivor（倖存區）的最大容量 (字節)
ECMX：年輕代中Eden（伊甸園）的最大容量 (字節)
DSS：當前需要survivor（倖存區）的容量 (字節)（Eden區已滿）
TT：持有次數限制
MTT ：最大持有次數限制
如果定位內存泄漏問題我一般使用如下命令：
Jstat -gcutil15469 2500 70
[root@ssss logs]# jstat -gcutil 15469 1000 300
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 1.46 26.54 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 46.54 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 47.04 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 65.19 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 67.54 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 87.54 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 88.03 4.61 30.14 35 0.872 0 0.000 0.872
1.48 0.00 5.56 4.62 30.14 36 0.874 0 0.000 0.874
1000 代表多久間隔顯示一次，
100 代表顯示一次。
S0 — Heap上的 Survivor space 0 區已使用空間的百分比
S1 — Heap上的 Survivor space 1 區已使用空間的百分比
E — Heap上的 Eden space 區已使用空間的百分比
O — Heap上的 Old space 區已使用空間的百分比
P — Perm space 區已使用空間的百分比
YGC — 從應用程序啓動到採樣時發生 Young GC 的次數
YGCT– 從應用程序啓動到採樣時 Young GC 所用的時間（單位秒）
FGC — 從應用程序啓動到採樣時發生 Full GC 的次數
FGCT– 從應用程序啓動到採樣時 Full GC 所用的時間（單位秒）
GCT — 從應用程序啓動到採樣時用於垃圾回收的總時間（單位秒）
如果有大量的FGC就要查詢是否有內存泄漏的問題了，圖中的FGC數量就比較大，並且執行時間較長，這樣就會導致系統的響應時間較長，如果對jvm的內存設置較大，那麼執行一次FGC的時間可能會更長。
如果爲了更好的證明FGC對服務器性能的影響，我們可以使用java visualVM來查看一下：
從上圖可以發現執行FGC的情況，下午3:10分之前是沒有FGC的，之後出現大量的FGC。
上圖是jvm堆內存的使用情況，下午3:10分之前的內存回收還是比較合理，但是之後大量內存無法回收，最後導致內存越來越少，導致大量的full gc。
下面我們在看看大量full GC對服務器性能的影響，下面是我用loadrunner對我們項目進行壓力測試相應時間的截圖：
從圖中可以發現有，在進行full GC後系統的相應時間有了明顯的增加，點擊率和吞吐量也有了明顯的下降。所以java內存泄漏對系統性能的影響是不可忽視的。
3、定位內存泄漏
當然通過上面幾種方法我們可以發現java的內存泄漏問題，但是作爲一名合格的高級工程師，肯定不甘心就把這樣的結論交給開發，當然這也的結論交給開發，開發也很難定位問題，爲了更好的提供自己在公司的地位，我們必須給開發工程師提供更深入的測試結論，下面就來認識一下MemoryAnalyzer.exe。java內存泄漏檢查工具利器。
首先我們必須對jvm的堆內存進行dump，只有拿到這個文件我們才能分析出jvm堆內存中到底存了些什麼內容，到底在做什麼？
MemoryAnalyzer的用戶我在這裏就不一一說明了，我的博客裏也有說明，下面就展示我測試的成功圖：
其中深藍色的部分就爲內存泄漏的部分，java的堆內存一共只有481.5M而內存泄漏的部分獨自佔有了336.2M所以本次的內存泄漏很明顯，那麼我就來看看那個方法導致的內存泄漏：
從上圖我們可以發現紅線圈着的方法佔用了堆內存的67.75%，如果能把這個測試結果交給開發，開發是不是應該很好定位呢。所以作爲一名高級測試工程師，我們需要學習的東西太多。
雖然不確定一定是內存泄漏，但是可以準確的告訴開發問題出現的原因，有一定的說服力。
本人剛剛完成了雲存儲架構師的培訓學習（包括了linux的內核瞭解、 shell的高級編程、linux安全的學習重點iptables和tcp/ip等各種協議的抓包分析、linux的集羣、性能調優等接下來還有dba的課程等待着我挑戰）。
友情推薦：ABC技術研習社
爲技術人打造的專屬A(AI),B(Big Data),C(Cloud)技術公衆號和技術交流社羣。
