注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

断尘居

温柔的男人像海洋。

 
 
 
 
 

日志

 
 

OutOfMemoryError分析过程  

2011-10-08 18:44:38|  分类: JVM/ HotSpot |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

最近在研究JVM优化方面的知识,今天就顺便用JVM的查看工具测试了一下当发生OutOfMemoryError的时候如何通过工具来分析出错原因。

需要的工具Eclipse Memory Analyzer。

1.在eclipse的run argument中输入以下VM参数(关于Xms,Xmx,Xmn的具体含义参考http://unixboy.iteye.com/blog /174173)。设置了堆空间为20M,年轻代为10M。通过参数-XX:+HeapDumpOnOutOfMemoryError指定发生 OutOfMemoryError的时候dump下内存(文件名为java_pid〈进程ID〉.hprof)。通过参数 -XX:+PrintGCDetails -Xloggc:gc.log设置程序输出gc的信息到gc.log文件。

2.以下为java代码

package com.fnk.spring.manager;

import java.util.LinkedList;

class TestGC {
    public static void main(String[] args) {
         LinkedList<String> l = new LinkedList<String>();
         while(true){
             l.add(new String("Testttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt"));
         }
    }
}


 3. 以下为gc.log文件。

先说一下日志输出的结构:(1.6和1.5略微有一些不同,只是1.6对于时间统计更加细致)

[GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]

<collector>GC收集器的名称

<starting occupancy1> 新生代在GC前占用的内存

<ending occupancy1> 新生代在GC后占用的内存

<pause time1> 新生代局部收集时jvm暂停处理的时间

<starting occupancy3> JVM Heap 在GC前占用的内存

<ending occupancy3> JVM Heap 在GC后占用的内存

<pause time3> GC过程中jvm暂停处理的总时间

那么第一行数据可以发现发生min GC的时候年轻代从7680K到1272K回收了6408K,堆空间从7680K到7632K回收了48K,说明有6360K的数据被转移到了年老代。

那么第二行数据可以发现发生Full GC的时候年轻代从1272K到0K回收了1272K,年老代从6360K到7629K增多了1269K,堆空间从7632K到7629K回收了3K。

通过观察年老代不断的增多,一直到上限10240K。最后当年轻代的数量达到7679K的时候就发生了outofmemory的错误。

可以发生eden的space是7680K,from和to space的都是1280k。因为from和to的空间不能同时使用,因此可用的年轻代空间是8960K。默认的eden和surver的空间比例是6:1.


0.386: [GC [PSYoungGen: 7680K->1272K(8960K)] 7680K->7632K(19200K), 0.0439756 secs] [Times: user=0.06 sys=0.00, real=0.05 secs]
0.430: [Full GC [PSYoungGen: 1272K->0K(8960K)] [PSOldGen: 6360K->7629K(10240K)] 7632K->7629K(19200K) [PSPermGen: 2059K->2059K(12288K)], 0.0241013 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]
0.460: [Full GC [PSYoungGen: 7680K->5068K(8960K)] [PSOldGen: 7629K->10240K(10240K)] 15309K->15308K(19200K) [PSPermGen: 2059K->2059K(12288K)], 0.0492533 secs] [Times: user=0.05 sys=0.00, real=0.05 secs]
0.512: [Full GC [PSYoungGen: 7680K->7680K(8960K)] [PSOldGen: 10240K->10240K(10240K)] 17920K->17920K(19200K) [PSPermGen: 2065K->2065K(12288K)], 0.0475882 secs] [Times: user=0.05 sys=0.00, real=0.05 secs]
0.559: [Full GC [PSYoungGen: 7680K->7480K(8960K)] [PSOldGen: 10240K->10240K(10240K)] 17920K->17720K(19200K) [PSPermGen: 2065K->2059K(12288K)], 0.0626773 secs] [Times: user=0.06 sys=0.00, real=0.06 secs]
0.622: [Full GC [PSYoungGen: 7680K->7680K(8960K)] [PSOldGen: 10240K->10240K(10240K)] 17920K->17920K(19200K) [PSPermGen: 2059K->2059K(12288K)], 0.0479926 secs] [Times: user=0.05 sys=0.00, real=0.05 secs]
0.671: [Full GC [PSYoungGen: 7680K->7679K(8960K)] [PSOldGen: 10240K->10240K(10240K)] 17920K->17919K(19200K) [PSPermGen: 2059K->2059K(12288K)], 0.0484853 secs] [Times: user=0.05 sys=0.00, real=0.05 secs]
0.719: [Full GC [PSYoungGen: 7679K->7679K(8960K)] [PSOldGen: 10240K->10240K(10240K)] 17919K->17919K(19200K) [PSPermGen: 2059K->2059K(12288K)], 0.0477472 secs] [Times: user=0.05 sys=0.00, real=0.05 secs]
0.767: [Full GC [PSYoungGen: 7679K->7679K(8960K)] [PSOldGen: 10240K->10240K(10240K)] 17919K->17919K(19200K) [PSPermGen: 2059K->2059K(12288K)], 0.0489797 secs] [Times: user=0.06 sys=0.00, real=0.06 secs]
1.892: [Full GC [PSYoungGen: 7679K->0K(8960K)] [PSOldGen: 10240K->137K(10240K)] 17919K->137K(19200K) [PSPermGen: 2059K->2059K(12288K)], 0.0100488 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
Heap
 PSYoungGen      total 8960K, used 209K [0x073e0000, 0x07de0000, 0x07de0000)
  eden space 7680K, 2% used [0x073e0000,0x07414518,0x07b60000)
  from space 1280K, 0% used [0x07b60000,0x07b60000,0x07ca0000)
  to   space 1280K, 0% used [0x07ca0000,0x07ca0000,0x07de0000)
 PSOldGen        total 10240K, used 137K [0x069e0000, 0x073e0000, 0x073e0000)
  object space 10240K, 1% used [0x069e0000,0x06a02490,0x073e0000)
 PSPermGen       total 12288K, used 2065K [0x029e0000, 0x035e0000, 0x069e0000)
  object space 12288K, 16% used [0x029e0000,0x02be4558,0x035e0000)


4. 通过memery analyzer可以分析出内存泄漏发生在linkedlist

总结:Memery Analyzer是一个很好的分析工具,在程序运行的时候可以通过Jmap dump下内存,然后通过它来分析。

  一个问题是,垃圾回收动作何时执行?

  • 当年轻代内存满时,会引发一次普通GC,该GC仅回收年轻代。需要强调的时,年轻代满是指Eden代满,Survivor满不会引发GC
  • 当年老代满时会引发Full GC,Full GC将会同时回收年轻代、年老代
  • 当永久代满时也会引发Full GC,会导致Class、Method元信息的卸载

  另一个问题是,何时会抛出OutOfMemoryException,并不是内存被耗空的时候才抛出

  • JVM98%的时间都花费在内存回收
  • 每次回收的内存小于2%
  评论这张
 
阅读(1024)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017