昨天遇到一个线上系统报 java.lang.OutOfMemoryError: PermGen space 错误,需要定位一下问题。很久之前到时弄过这个,现在还真有点不记得了,但这个真的是一个非常有意思的问题,值得好好研究一下。

    首先第一反应当然是加上-XX:+PrintGCDetails参数来看具体的GC日志,但是由于程序是tomcat启动的,担心里面封装的东西太多不好定位,既然在windows下面,所以还是借助可视化工具好了。

    然后我们来看一下这个错误的产生原因,在网上找到一段解释,说的很不错,贴过来借用一下:)

 PermGen space的全称是Permanent Generation space,是指内存的永久保存区域,这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中,它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理,所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误,这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。

    那么我们先加大PermGen的初始内存大小,linux下在catalina.sh文件的开头加上

  1. JAVA_OPTS="-Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m" 

    windows下在catalina.bat的文件开头加上

  1. set JAVA_OPTS=-Xms1024m -Xmx1024m -XX:PermSize=256M -XX:MaxPermSize=256m 

比较悲剧的是有个兄弟把这句话写错了,我被告知加了这个参数仍然报这个错。

    接着我们还是用可视化的内存查看工具来定位一下具体的问题。对于jdk6首选当然是自带的工具啦,比较常用的有jconsole和jvisualvm(使用后发现后者更强大,因为有丰富的插件支持)。这次又遇到一个比较诡异的问题,就是分析工具打开后居然找不到tomcat进程(事后发现居然启动的是jre,改成jdk应该就可以了)。既然本地不让连,我就远程连接得了,打开JMX即可。和上面一样,在catalina.sh或catalina.bat文件的开头的JAVA_OPTS里面加上

  1. -Djava.rmi.server.hostname=192.168.1.101 -Dcom.sun.management.jmxremote.port=9000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false  

    启动程序以后用netstat查看一下端口是否正确打开,以确保远程可以连接上。我这里偷懒了下,把authenticate关掉了,要是打开需要设置一些权限的东西,比较麻烦。这个设置在我本地的PC机上生效,但是在服务器上居然不行,可能装了什么软件把端口给封了,所以我只好再犯下贱,把端口改成1000。打开jvisualvm,点击file -> add JMX connection,然后加上localhost:1000就连上了。

    等连上程序以后,观察一段时间的内存变化状况,我重点看了下Perm的情况,一直稳定在94m的样子,运行一天一切正常。可能是之前设置Perm内存大小没有生效,因为Perm默认初始化是16m,最大是64m,而实际占用量确实有可能导致这个问题,从目前的现象来看应该是不会再出现这个问题了。

    如果需要更进一步定位问题,还可以使用btrace去查看某个方法具体被调用的地方。这样可以定位到某些方法是否按预期执行。

 


    这里简单介绍一下jvisualvm吧,真的是一个内存分析的利器。使用后发现真的非常强大,特别是visualgc的插件,界面如下:

    是不是特别的清楚,所有内存状况一目了然?!但你打开你的jdk/bin下这个jvisualvm工具是会失望,因为默认没有安装这个插件。在tool/plugin菜单下可以找到这个插件,赶快装上吧。安装完,重启一下jvisualvm,再连接应用程序就可以看到了。

参考文章:
1.  http://blogs.sun.com/klc/entry/visualgc_plugin_for_visualvm
2. 《分布式Java应用:基础与实践http://book.51cto.com/art/201011/235600.htm
3. https://visualvm.dev.java.net/