经过工程师现场对该系统的观察，发现JVM的heap在快速增长，经过一天的时间基本上4000M的内存基本上就用光了。垃圾回收的效果不是很理想。在系统中查看JVM的线程，发现线程的占用内存增长很快，基本上达到物理内存的62%也就是4.8G左右，就会宕机。

2.日志和heapdump分析

     1.heapdump分析

     2.日志分析

    JVMDUMP006I 正在处理转储事件“systhrow”，详细信息“java/lang/OutOfMemoryError” － 请稍候。

     JVMDUMP006I 正在处理转储事件“systhrow”，详细信息“java/lang/OutOfMemoryError” － 请稍候。

     JVMDUMP006I 正在处理转储事件“systhrow”，详细信息“java/lang/OutOfMemoryError” － 请稍候。

     JVMDUMP006I 正在处理转储事件“systhrow”，详细信息“java/lang/OutOfMemoryError” － 请稍候。

     JVMDUMP006I 正在处理转储事件“systhrow”，详细信息“java/lang/OutOfMemoryError” － 请稍候。

     JVMDUMP006I 正在处理转储事件“systhrow”，详细信息“java/lang/OutOfMemoryError” － 请稍候。

     JVMDUMP006I 正在处理转储事件“systhrow”，详细信息“java/lang/OutOfMemoryError” － 请稍候

3.问题分析

在图中我们可以看到(打红标的)代码部分占用资源很大。而且使用的数量也是很多。没有在一定时间内释放，引起内存不断上涨，在日志中也能看到在符合引起我们系统宕机前抛出(OutOfMemoryError)。所以综合上述导致宕机原因是代码中存在内存泄漏导致内存使用率快速上涨。

4.解决方案

    这个很有可能是web应用代码中的漏洞。在经过开发人的确认后，证明确实是应用中使用了Hibernate 3.0的连接池dbcp连接池造成问题的根本原因。

    在开发人员修改代码以后，经过一天的观察JVM的heap没有在快速上涨，而且系统运行稳定。证明在问题确实是Hibernate 3.0的连接池dbcp连接池引起的。（如图）