性能分析系列-小命令保证大性能(4)

GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略，通过统计GC时间来预测是否要OOM了，提前抛出异常，防止OOM发生。Sun 官方对此的定义是：“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是，超过98%的时间用来做GC并且回收了不到2%的堆内存。用来避免内存过小造成应用不能正常工作。

可以看到当堆中的对象无法被收回的时候，就提前遇警报出这样的错误，此时内存并没有溢出，这个特性在JDK中是默认添加的。

3、DUMP文件分析
将dump文件导入VisualVM工具中，如下图所示：

Paste_Image.png

通过上图可以看出类结构图中，最占用内存的是char[]，LinkedHashMap和String三项。但是这三项的实例数并没有占满，看样子不会内存溢出，怎么才能具体分析呢？原因就在于GC overhead limt exceed，这个错并不会在内存真正溢出才会报，所以通过dump文件，我们只能自己去判断分析，哪些项有可能会造成溢出，我们进入char[]项具体来看，会发现里面有很多hessian的url字符被缓存，通过排除程序可以看到由于底层中间件程序为了提高“性能”，将每次调用的url都缓存起来，不用每次都生成，但没有相应缓存释放操作，于是造成了大量字符对象长期持有从而报错，在此就不截图来具体看代码，涉及一些公司信息。

4、问题解决方案

• 可以添加JVM的启动参数来去掉提前报警限制：-XX:-UseGCOverheadLimit，于其让应用每次都提前报警，还不如让暴风雨来的更猛些，直接内存溢出，因为服务器是集群，其中一台挂掉不会影响线上正常交易，同时也方便我们通过日志来排错。

• 通过排查程序，检查系统是否有使用大内存的代码不释放或死循环。

原文转自：http://www.jianshu.com/p/6df2963fe94e