異常內存溢出有個復雜的說明，為此學習啦小編為大家整理推薦了以下內容，希望大家喜歡。

　　was manage內存溢出

　　WAS 內存溢出(OutofMemory)問題分析常用方法

　　簡述 OOM(內存溢出)：

　　內存溢出是指在應用系統(tǒng)中存在無法回收的內存或內存使用的過多，最終導致應用程序無法為新的對象分配內存空間，這時Java運行時會拋出一個 OutOfMemoryError 的異

　　常，簡稱 OOM。

　　簡述 Java堆(Java Heap)：

　　JVM 內存從邏輯上來說分為多個空間，Java堆是 JVM 所管理的內存空間中最大的一塊。我們可以通過 JVM 啟動參數(shù) -Xms、-Xmx 來設定它的大小。GC 工作的主要區(qū)域也是

　　在這里，因為基本上所有的對象實例的內存都是在這里分配的。

　　簡述 GC (垃圾收集器)：

　　在 JVM 中，內存的釋放是由垃圾收集器(GarbageCollection，GC)完成的，當一個對象不再被引用的時候，GC 便回收它所占用的內存空間。

　　-----------------------------------

　　觸發(fā)內存溢出的可能原因：

　　1、集合類中(List、MAP)有對對象的引用，使用完后未清空

　　2、內存一次性加載的數(shù)據(jù)量過多

　　3、內存產生大量碎片，沒有連續(xù)可用空間

　　4、代碼中存在死循環(huán)或遞歸調用

　　5、JVM 啟動參數(shù)內存值設定的過小

　　6、系統(tǒng)物理內存過小

　　-----------------------------------

　　在分析問題時，我們需要收集以下日志：

　　GC日志：native_stderr.log (在 JVM 啟動參數(shù)中加入 -verbose:gc 打開詳細垃圾回收)

　　通過 GC 日志native_stderr.log查看垃圾回收情況

　　應用系統(tǒng)日志：SystemOut.log

　　查看具體錯誤信息

　　線程轉儲：javacore

　　通過 heapdump 分析可疑泄漏對象

　　堆轉儲：heapdump

　　通過 javacore 分析線程執(zhí)行狀態(tài)

　　------------------------------------

　　生成javacore和heapdump，可以多次收集，然后通過工具比較分析，這樣更容易發(fā)現(xiàn)問題

　　[root@was01 bin]# ./wsadmin.sh -user wasadmin -password password

　　設置jvm環(huán)境變量

　　wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]

　　生成javacore文件：

　　wsadmin>$AdminControl invoke $jvm dumpThreads

　　找到JVM對象名字

　　wsadmin>set objectName [$AdminControl queryNames type=JVM,process=server1,*]

　　生成heapdump文件：

　　wsadmin>$AdminControl invoke $objectName generateHeapDump

　　------------------------------------

　　在 WAS 中，我們可以嘗試以下方法，緩解內存溢出問題，具體方法請根據(jù)實際情況判斷：

　　1、更改垃圾回收算法

　　2、優(yōu)化 JVM 啟動參數(shù)

　　3、增加 JVM 內存大小要想更好的解決 java.lang.OutOfMemoryError 的問題，我們需要從應用程序入手，因為優(yōu)化程序帶來的性能改善遠遠高于對 WAS 的調試。

　　-----------------------------------------

　　以下是對內存泄漏的幾種分類：(摘抄自網(wǎng)絡)

　　1. 常發(fā)性內存泄漏。發(fā)生內存泄漏的代碼會被多次執(zhí)行到，每次被執(zhí)行的時候都會導致一塊內存泄漏。

　　2. 偶發(fā)性內存泄漏。發(fā)生內存泄漏的代碼只有在某些特定環(huán)境或操作過程下才會發(fā)生。常發(fā)性和偶發(fā)性是相對的。對于特定的環(huán)境，偶發(fā)性的也許就變成了常發(fā)性的。所以測試環(huán)境和測試方法對檢測內存泄漏至關重要。

　　3. 一次性內存泄漏。發(fā)生內存泄漏的代碼只會被執(zhí)行一次，或者由于算法上的缺陷，導致總會有一塊且僅有一塊內存發(fā)生泄漏。

　　4. 隱式內存泄漏。程序在運行過程中不停的分配內存，但是直到結束的時候才釋放內存。嚴格的說這里并沒有發(fā)生內存泄漏，因為最終程序釋放了所有申請的內存。但是對于一個服務器程序，需要運行幾天，幾周甚至幾個月，不及時釋放內存也可能導致最終耗盡系統(tǒng)的所有內存。所以，我們稱這類內存泄漏為隱式內存泄漏。