整理SSH框架容易出现的内存泄漏情况

前言

最近几周，一直忙着处理上届毕业学长的遗留项目问题，一个基于Spring-Struts-Hibernate框架的网站系统。上线那边隔几天系统就崩溃一次，真是弄得人心惶惶，终于测试人员还是发现了报错的log…OOM（Out Of Memory，内存溢出），通俗的理解一下，大概就是内存不够用了，看了人家的任务管理器，很强…服务器占了17G内存…总共是64G…达到Tomcat默认设置的所谓的本机内存的1/4了已经。


这是当时的报错信息，我的理解就是，内存因为某种原因，不够用了，所以系统崩溃…
同学给了几种可能的情况：1.jvm小（17G，否了）。2.触发死循环（网站很难出现死循环吧…）。3.线程回收机制有问题，无法回收（诶！就是这个！）。
经过多方查找资料，我们这个系统，应该就是内存泄漏导致的内存溢出现象。

内存泄漏是什么？

    内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。

作为一个网站项目，而且存在动态分配的内存，那么我暂时只想得到定时器这个东西。
本项目中，用了两个不同的定时器，Timertask和Quartz。

Timertask是JDK自带的定时器工具，于情于理，我觉得问题不在这。

PS: 好吧，其实timertask也有问题…

Quartz是一个开源作业调度框架框架，框架结合着用很容易出问题…

几种内存泄漏的可能

在Spring框架中使用Quartz作业调度框架

由Spring官方API指出：

/**
 * Listener that flushes the JDK's {
   @link java.beans.Introspector JavaBeans Introspector}
 * cache on web app shutdown. Register this listener in your <code>web.xml</code> to
 * guarantee proper release of the web application class loader and its loaded classes.
 *
 * <p><b>If the JavaBeans Introspector has been used to analyze application classes,
 * the system-level Introspector cache will hold a hard reference to those classes.
 * Consequently, those classes and the web application class loader will not be
 * garbage-collected on web app shutdown!</b> This listener performs proper cleanup,
 * to allow for garbage collection to take effect.
 *
 * <p>Unfortunately, the only way to clean up the Introspector is to flush
 * the entire cache, as there is no way to specifically determine the
 * application's classes referenced there. This will remove cached
 * introspection results for all other applications in the server too.
 *
 * <p>Note that this listener is <i>not</i> necessary when using Spring's beans
 * infrastructure within the application, as Spring's own introspection results
 * cache will immediately flush an analyzed class from the JavaBeans Introspector
 * cache and only hold a cache within the application's own ClassLoader.
 *
 * <b>Although Spring itself does not create JDK Introspector leaks, note that this
 * listener should nevertheless be used in scenarios where the Spring framework classes
 * themselves reside in a 'common' ClassLoader (such as the system ClassLoader).</b>
 * In such a scenario, this listener will properly clean up Spring's introspection cache.
 *
 * <p>Application classes hardly ever need to use the JavaBeans Introspector
 * directly, so are normally not the cause of Introspector resource leaks.
 * Rather, many libraries and frameworks do not clean up the Introspector:
 * e.g. Struts and Quartz.
 *
 * <p>Note that a single such Introspector leak will cause the entire web
 * app class loader to not get garbage collected! This has the consequence that
 * you will s