本文来自于我的同事Roy的一次分享,感觉蛮有用的,保存下来,以备后用。
1 分析工具
1) 动态分析工具
Jprofiler
具体Jprofiler在我们的FTPC的配置,可以参考我在sharing上的一篇分享文章 http://bu2-devdb01:4132/Lessons%20Learned/Jprofiler监控FTPC%20SA的内存配置.aspx
2) 静态分析工具
a: 在启动java的时候加上参数 -XX:+HeapDumpOnOutOfMemoryError,这样如果由于OOM导致JVMcrash的时候可以便于我们分析,生成的heap dump文件名字的命名规范如下,java_pidxxxx.hprof
b: elcipsemat
IBM heap ana:我们MR比较喜欢用这个IBM的工具进行OOM诊断,启动方式
java -Xmx1600 -jar ha396.jar,然后选择文件打开生成的heapdump.
2 Java 内存机制 和可能出现的OOM Exception
1对于从事C、C++程序开发的开发人员来说,担负着每一个对象生命开始到终结的维护责任。
对于Java程序员来说,不需要在为每一个new操作去写配对的delete/free,不容易出现内容泄漏和内存溢出错误。不过,也正是因为Java程序员把内存控制的权力交给了JVM,一旦出现泄漏和溢出,如果不了解JVM是怎样使用内存的,那排查错误将会是一件非常困难的事情。下面介绍一下java出现的OOM有关的 Exception和可能出现的方式
A Exception in thread"main" java.lang.OutOfMemoryError: PermGen space
publicstatic void main(String[] args) {
//使用List保持着常量池引用,压制Full GC回收常量池行为
List<String> list = newArrayList<String>();
// 10M的PermSize在integer范围内足够产生OOM了
int i = 0;
while (true) {
list.add(String.valueOf(i++).intern());
}
}
这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域(包括常量池: 静态变量),它和和存放Instance的Heap区域不同,GC(GarbageCollection)不会在主程序运行期对PermGen space进行清理,所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误动态生成的类,加载如Spring、Hibernate对类进行增强时,都会使用到CGLib这类字节码技术,当增强的类越多,就需要越大的方法区用于保证动态生成的Class可以加载入内存,以上是PermGen space区的常量池内存泄露导致的OOM.
Bjava.lang.OutOfMemoryError:Java heap space,运行中产生的对象,被缓存的实例(Cache)对象,大的map,list引用大的对象等等,都会保存于此(Heap)
publicstatic void main(String[] args) {
List<String> list = newArrayList<String>();
int i = 0;
while (true) {
list.add(new String(“test”));
}
}
CException in thread"main" java.lang.StackOverflowError
栈帧太多,也就是函数调用层级过多)导致。检查是否有死递归的情况~
/**
* VM Args:-Xss128k
*/
publicclass JavaVMStackSOF {
private int stackLength = 1;
public void stackLeak() {
stackLength++;
stackLeak();
}
public static void main(String[] args)throws Throwable {
JavaVMStackSOF oom = newJavaVMStackSOF();
try {
oom.stackLeak();
} catch (Throwable e) {
System.out.println("stack length:" + oom.stackLength);
throw e;
}
}
}
2 Java 垃圾回收机制
基本回收算法
其实这些算法和OOM没有太大关系,OOM产生的原因很简单,就是需要内存的时候没有内存了,但是对垃圾回收机制的理解可以让我们知道-Xmx -Xms Xmn – MaxPermSize参数该怎么样设置,避免频繁full-GC(Full-GC会造成app短暂停顿,此时app是不会响应任何客户端请求的),并且合理设置参数.(1对于缓存过多的系统可以增大-Xmx,通过减小Xmn调整新生代年老代比例,2对于瞬时对象过多的系统,年老代的heap可以不用分配那么大)
分代垃圾回收详述
3实战演练
背景介绍
1这个是XXX 的一个SupportCase,他们用我们XXX的平台软件开发了一个从ERP系统导入订单到我们系统的一个转换程序,他们把ERP系统的所有订单写到一个txt文件里面。然后用他们的写的应用来转换txt中的单信息到我们系统的Lot,workorder对象等等。但是他们发现有个问题,就是导入的txt文件如果过大的话,就会有可能报出OOM异常,这个对他们影响是很大的,不但造成程序crash,而且他们不知道当前导入了多少order,没法回滚脏数据。于是Support建议他们加大Client端的内存(比如-Xmx2G),但是这样还是会有问题的,因为你不知道从ERP导出的txt的文件有多大,所以你不知道要设置多大的内存才是合适的.
2
从下面这张图这里可以让大家猜测大概是什么问题导致的内存泄露
这个是用 IBM heap ana分析heap dump的视图,大家可以看一下,有96%内存都在pnuts/lang/context中,其中92%内存是被lot对象占用的,lot对象保存到Vector中,所以是由于lot对象保存在Vector中,但是vector没有及时释放这些对象导致的。所以可以通过vector.addElement去全文检索,看看是否有使用的vector缓存没有及时释放的地方。
3实际内存泄露的代码.(绿色标注的那行)
Please locate the lines of code around line 2736 ofSubroutine ImportWoFile. Following is the some pieces of the codes about it:
foreach orderItem(vecOrderItems.elements())
{
….
newLot = createLot(strLotName, workOrder)
…
newLot.save()
…
if (blnSaveOK == false)
{
……
}else
{
//Actually leak script vecLot.addElement(newLot)
….
}
}
最后搜索程序,发现vecLot的句柄一直被context全局类持有,这样看来,由于导入的txt文件过大(产生对象过多),很容易发生OOM
Obviously, the lot of vectLot will be tremendous if theywant to import a large wo file at one time. So it will consume the memory ofJVM.