WAS 内存溢出（OutofMemory）问题分析常用方法

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. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。