步骤如下:
我启动一个web容器,在其中配置一个selvelt,selvelt启动时会执行一条问题程序,导致堆内存溢出,代码如下
public class myselvelt extends HttpServlet {
private String[] strings = new String[1000];
public void init(ServletConfig config) {
System.out.println("-----------------------------");
Timer timer = new Timer();
timer.schedule(new mytime(), 10000);
}
class mytime extends TimerTask{
@Override
public void run() {
System.out.println("-------------mytime----------------");
Map<String,Object> m = new HashMap<String,Object>();
int i = 0;
do{
OutOfMemoryTest test = new OutOfMemoryTest();
m.put(String.valueOf(i), test);
i++;
}while(i<100000);
}
}
protected void doGet(HttpServletRequest req,HttpServletResponse resp) throws ServletException,java.io.IOException
{
resp.getWriter().println("I am httpServlet doGet()");
}
protected void doPost(HttpServletRequest req,HttpServletResponse resp) throws ServletException,java.io.IOException
{
resp.getWriter().println("I am httpServlet doPost()");
}
public void destory(ServletConfig config){
}
}
然后设置容器运行参数:-Xms128m -Xmx256m -XX:MaxPermSize=256m
启动程序,直到堆内存溢出
首先由此饼状图就可以看出问题出现a、b上,再看两问题的简单描述,b是出现在org.apache.catalina.loader.WebappClassLoader 中的,此是容器涉及的区域,可以排除,再看a描述为一个Timer-5的线程占据的51%的堆空间,所以基本可以断定问题出现在a上(这里还有一个比较直观,但不高效的办法,就是重新设置一下运行容器的参数,运行直到出错,再导入dump的文件,就可以对比饼状图,百分百变化很明显的就是问题原因出现的位置)
先看到累积点的最短路径
然后再看累积对象所在树的详情
可以看到积累了很多HashMap
然后切换一个视图查看
在第一行输入问题线程名(Timer-5)进行查询,进入找到累积点(堆占据最大)
可以看到累积了22364个hashMap<String,OutOfMemoryTest>对象,这就是问题的根源
然后再跟踪堆栈找到问题代码所在位置
此处比较简单,就是一个Timer-->myselvelt-->OutOfMemoryTest-->OutOfMemoryError
可以看到问题可能是myselvelt.java的34行,OutOfMemoryTest.java的7行
找到对应的代码区查找
这里基本就可以会转到文章开始了,也就是问题实例,是myselvelt中的问题所在点(myselvelt.java的34行)
通过jdk自带的jmap命令获取 jmap -dump:format=b,file=D:\dump\dumpName.hprof [pid]
在jdk启动加参数中加: -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\dump\ ,然后应用启动后出现内存异常则会自动导出dump文件,默认的文件名是:java_pid<进程号>.hprof。
注意:获取dump文件必须是一出现内存异常就获取dump文件,这样获取的文件信息才比较准确,如果过了一段时间在导出dump文件,就会因gc的缘故,导致信息不准确,所以推荐第二种方式获取dump文件。
转载:
因篇幅问题不能全部显示,请点此查看更多更全内容