工作原因,需要找出程序中内存泄漏的地方(泄漏现象:JAVA进程的内存,一直在缓慢的增长,到最后出现OutOfMemory),当然市场上有很多的这样剖析工具了象Jprobe等,但是因为商业原因,没能采用:(.
于是就用java本身的-Xrunhprof参数+HPjmeter,进行剖析,经过跟踪分析,发现有大量的Thread一直是活动对象,及时run()已经执行过!类似代码如下:
Vector v = new Vector();
for (int k=0;k<10;k++)
v.addElement(new Thread());
....//other somethings.
for (int k=0;k<v.size();k++) {
Thread t= (Thread)v.elementAt(k);
t.run();
v.removeElementAt(k);
}
将heap=dump参数打开,用HPjemter分析prof文件日志,发现Thread对象,一直还是活动的,并且监测到memory leak.
我们再来看看代码,把Thread放到一个类似的队列里边去,然后执行,最后从队列移出,看似没有什么问题,其实这就是Thread滥用的地方.如果开始一个Thread,只是为了运行run方法,而不需要start,那就将Thread换成Runnable对象好了,那么内存泄漏的机会就没有了.
而且此泄漏跟JDK版本也有关系的,我在JDK5上运行以上代码,就没有监测到泄漏,而在1.4和1.3上,这样的泄漏就一直存在.!
最后,建议创建线程,最好还是用JDK推荐的Runnable方式.!
于是就用java本身的-Xrunhprof参数+HPjmeter,进行剖析,经过跟踪分析,发现有大量的Thread一直是活动对象,及时run()已经执行过!类似代码如下:
Vector v = new Vector();
for (int k=0;k<10;k++)
v.addElement(new Thread());
....//other somethings.
for (int k=0;k<v.size();k++) {
Thread t= (Thread)v.elementAt(k);
t.run();
v.removeElementAt(k);
}
将heap=dump参数打开,用HPjemter分析prof文件日志,发现Thread对象,一直还是活动的,并且监测到memory leak.
我们再来看看代码,把Thread放到一个类似的队列里边去,然后执行,最后从队列移出,看似没有什么问题,其实这就是Thread滥用的地方.如果开始一个Thread,只是为了运行run方法,而不需要start,那就将Thread换成Runnable对象好了,那么内存泄漏的机会就没有了.
而且此泄漏跟JDK版本也有关系的,我在JDK5上运行以上代码,就没有监测到泄漏,而在1.4和1.3上,这样的泄漏就一直存在.!
最后,建议创建线程,最好还是用JDK推荐的Runnable方式.!