Java的垃圾回收機制給了程序猿便利，我們可以不需要顯式釋放資源。但想高枕無憂卻是不能，OOM像個隱藏在暗處的幽(hua)靈(nong)，威脅著可憐、弱小又漂亮的程序猿。
一般來說，一個健康的程序，它是不應該出現OOM的。內存里的對象從生到死，井然有序。但由于一些人為的失誤，往往會讓一些對象逃過GC的制裁，跳出GC外，不在垃圾中。這個時候，內存泄漏就發生了。
內存泄露，是指程序在申請內存并且用完這塊內存后（對象不再需要了），沒有釋放已申請的內存空間。少數偶然的內存泄漏，雖然不太好，但問題不大，我們也不至于對那點內存摳摳搜搜的。但如果是內存不斷泄漏，直到新的對象沒有足夠的空間生成，就會導致OOM。
拋出OOM異常
當程序拋出OutOfMemoryError，如果你自認不是太摳，給了這個程序足夠的空間，那么可以懷疑有內存泄漏
內存持續上升
一個健康的程序應該有平穩的新陳代謝，內存占用應該維持在一定范圍。但如果內存持續飆升，甚至到達了一個危險的值，那么可以懷疑有內存泄漏。
查看GC情況
首先獲取到應用的pid，可以使用java的jps命令，或者ps -ef|grep 應用名關鍵詞
可以看到Eden(E)持續造對象，并且滿了之后，老年代(O)增加，E區騰空后繼續造對象。（程序多執行一段時間，或者造對象速度提快點，最終會拋出OOM）
查看存活對象
根據存活對象的不正常增長情況，分析程序中哪些地方用到了這種對象，也可以大致推斷出可能的內存泄漏處。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
