was manage內存溢出
異常內存溢出有個復雜的說明，為此學習啦小編為大家整理推薦了以下內容，希望大家喜歡。
was manage內存溢出
WAS 內存溢出(OutofMemory)問題分析常用方法
簡述 OOM(內存溢出)：
內存溢出是指在應用系統中存在無法回收的內存或內存使用的過多，最終導致應用程序無法為新的對象分配內存空間，這時Java運行時會拋出一個 OutOfMemoryError 的異
常，簡稱 OOM。
簡述 Java堆(Java Heap)：
JVM 內存從邏輯上來說分為多個空間，Java堆是 JVM 所管理的內存空間中最大的一塊。我們可以通過 JVM 啟動參數 -Xms、-Xmx 來設定它的大小。GC 工作的主要區域也是
在這里，因為基本上所有的對象實例的內存都是在這里分配的。
簡述 GC (垃圾收集器)：
在 JVM 中，內存的釋放是由垃圾收集器(GarbageCollection，GC)完成的，當一個對象不再被引用的時候，GC 便回收它所占用的內存空間。
-----------------------------------
觸發內存溢出的可能原因：
1、集合類中(List、MAP)有對對象的引用，使用完后未清空
2、內存一次性加載的數據量過多
3、內存產生大量碎片，沒有連續可用空間
4、代碼中存在死循環或遞歸調用
5、JVM 啟動參數內存值設定的過小
6、系統物理內存過小
-----------------------------------
在分析問題時，我們需要收集以下日志：
GC日志：native_stderr.log (在 JVM 啟動參數中加入 -verbose:gc 打開詳細垃圾回收)
通過 GC 日志native_stderr.log查看垃圾回收情況
應用系統日志：SystemOut.log
查看具體錯誤信息
線程轉儲：javacore
通過 heapdump 分析可疑泄漏對象
堆轉儲：heapdump
通過 javacore 分析線程執行狀態
------------------------------------
生成javacore和heapdump，可以多次收集，然后通過工具比較分析，這樣更容易發現問題
[root@was01 bin]# ./wsadmin.sh -user wasadmin -password password
設置jvm環境變量
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 中，我們可以嘗試以下方法，緩解內存溢出問題，具體方法請根據實際情況判斷：
1、更改垃圾回收算法
2、優化 JVM 啟動參數
3、增加 JVM 內存大小要想更好的解決 java.lang.OutOfMemoryError 的問題，我們需要從應用程序入手，因為優化程序帶來的性能改善遠遠高于對 WAS 的調試。
-----------------------------------------
以下是對內存泄漏的幾種分類：(摘抄自網絡)
1. 常發性內存泄漏。發生內存泄漏的代碼會被多次執行到，每次被執行的時候都會導致一塊內存泄漏。
2. 偶發性內存泄漏。發生內存泄漏的代碼只有在某些特定環境或操作過程下才會發生。常發性和偶發性是相對的。對于特定的環境，偶發性的也許就變成了常發性的。所以測試環境和測試方法對檢測內存泄漏至關重要。
3. 一次性內存泄漏。發生內存泄漏的代碼只會被執行一次，或者由于算法上的缺陷，導致總會有一塊且僅有一塊內存發生泄漏。
4. 隱式內存泄漏。程序在運行過程中不停的分配內存，但是直到結束的時候才釋放內存。嚴格的說這里并沒有發生內存泄漏，因為最終程序釋放了所有申請的內存。但是對于一個服務器程序，需要運行幾天，幾周甚至幾個月，不及時釋放內存也可能導致最終耗盡系統的所有內存。所以，我們稱這類內存泄漏為隱式內存泄漏。