apache standard.jar 包 c:forEach标签是否存在着内存泄露？

近来公司的服务器内存占用很大，运行一段时间，gc就占用cpu 100%，然后tomcat拒绝访问。

本地调试了几天，代码实在看不出问题。网上搜索了大量的文章研读，必须江南白衣，和javaeye上关于gc的文章，对服务器进行调试，还是没用。

服务器上才gc日志如下：

210.970: [CMS-concurrent-mark-start]
211.266: [CMS-concurrent-mark: 0.211/0.295 secs] [Times: user=0.49 sys=0.00, real=0.29 secs]
211.266: [CMS-concurrent-preclean-start]
211.270: [CMS-concurrent-preclean: 0.004/0.004 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

211.270: [CMS-concurrent-abortable-preclean-start]
215.141: [CMS-concurrent-abortable-preclean: 1.351/3.871 secs] [Times: user=2.64 sys=0.11, real=3.87 secs]

215.142: [GC[YG occupancy: 132189 K (235968 K)]
215.142: [Rescan (parallel) , 0.0644930 secs]
215.207: [weak refs processing, 0.1014540 secs] [1 CMS-remark: 135253K(262144K)] 267442K(498112K), 0.1661810 secs] [Times: user=0.30 sys=0.00, real=0.16 secs]
215.308: [CMS-concurrent-sweep-start]
215.419: [CMS-concurrent-sweep: 0.108/0.111 secs] [Times: user=0.14 sys=0.02, real=0.11 secs]
215.419: [CMS-concurrent-reset-start]
215.448: [CMS-concurrent-reset: 0.029/0.029 secs] [Times: user=0.04 sys=0.02, real=0.03 secs]

无奈，用jprofiler调试，过滤程序中所有使用过的pojo，发现凡是jsp用了 <c:forEach...这个标签的，每刷新一次，所用的model类的实例就会增加，在jprofiler中手工点击垃圾回收按钮后，回收不了。但是其他的地方，都可以回收。

通过jprofiler追踪引用，最好追踪到对应的jsp的编译后的文件，下面是部分代码

 private boolean _jspx_meth_c_005fforEach_005f2(PageContext _jspx_page_context)
          throws Throwable {
    PageContext pageContext = _jspx_page_context;
    JspWriter out = _jspx_page_context.getOut();
    //  c:forEach
    org.apache.taglibs.standard.tag.rt.core.ForEachTag _jspx_th_c_005fforEach_005f2 = (org.apache.taglibs.standard.tag.rt.core.ForEachTag) _005fjspx_005ftagPool_005fc_005fforEach_0026_005fvar_005fitems.get(org.apache.taglibs.standard.tag.rt.core.ForEachTag.class);
    _jspx_th_c_005fforEach_005f2.setPageContext(_jspx_page_context);
    _jspx_th_c_005fforEach_005f2.setParent(null);
    // /html/study/setMustCourse/orgListCourse.jsp(22,3) name = var type = java.lang.String reqTime = false required = false fragment = false deferredValue = false expectedTypeName = null deferredMethod = false methodSignature = null
    _jspx_th_c_005fforEach_005f2.setVar("orgCourse");
    // /html/study/setMustCourse/orgListCourse.jsp(22,3) name = items type = java.lang.Object reqTime = true required = false fragment = false deferredValue = false expectedTypeName = null deferredMethod = false methodSignature = null
    _jspx_th_c_005fforEach_005f2.setItems((java.lang.Object) org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${courseInfoList}", java.lang.Object.class, (PageContext)_jspx_page_context, null, false));
//在这里把request中courseInfoList赋值给_jspx_th_c_005fforEach_005f2的item属性。

    int[] _jspx_push_body_count_c_005fforEach_005f2 = new int[] { 0 };
    try {
      int _jspx_eval_c_005fforEach_005f2 = _jspx_th_c_005fforEach_005f2.doStartTag();
      if (_jspx_eval_c_005fforEach_005f2 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
        do {
          out.write("\r\n");
          out.write("\t\t\t\t<option style=\"color:blue\" value='");
          out.write((java.lang.String) org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${orgCourse.courseId}", java.lang.String.class, (PageContext)_jspx_page_context, null, false));
          out.write("' title=\"");
          out.write((java.lang.String) org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${orgCourse.courseTitle}", java.lang.String.class, (PageContext)_jspx_page_context, null, false));
          out.write('"');
          out.write('>');
          out.write((java.lang.String) org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${orgCourse.courseCode}", java.lang.String.class, (PageContext)_jspx_page_context, null, false));
          out.write("&nbsp;&nbsp;");
          out.write((java.lang.String) org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${orgCourse.courseTitle}", java.lang.String.class, (PageContext)_jspx_page_context, null, false));
          out.write(" </option>\r\n");
          out.write("\t\t\t");
          int evalDoAfterBody = _jspx_th_c_005fforEach_005f2.doAfterBody();
          if (evalDoAfterBody != javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN)
            break;
        } while (true);
      }
      if (_jspx_th_c_005fforEach_005f2.doEndTag() == javax.servlet.jsp.tagext.Tag.SKIP_PAGE) {
        return true;
      }
    } catch (Throwable _jspx_exception) {
      while (_jspx_push_body_count_c_005fforEach_005f2[0]-- > 0)
        out = _jspx_page_context.popBody();
      _jspx_th_c_005fforEach_005f2.doCatch(_jspx_exception);
    } finally {
      _jspx_th_c_005fforEach_005f2.doFinally(); //在这里进行属性的清除
      _005fjspx_005ftagPool_005fc_005fforEach_0026_005fvar_005fitems.reuse(_jspx_th_c_005fforEach_005f2);
    }
    return false;
  }

无奈，下载apache standard的源代码，发现javax.servlet.jsp.jstl.core.LoopTagSupport类中代码如下：

public void doFinally() {
	/*
	 * Make sure to un-expose variables, restoring them to their
	 * prior values, if applicable.
         */
	unExposeVariables();
    }
	}

没有对item属性清除。

于是hack子类 ForEachSupport的代码，增加了一个方法

public void doFinally() {
		super.doFinally();
		items = null;
		rawItems = null;
	}

然后用jprofiler进行测试，发现可以回收了。

存在的疑问如下：
1. ForEachSupport类，本身有个realease方法，貌似一直没有执行

public void release() {
        super.release();
        items = null;
        rawItems = null;
    }

2. c:forEach标签真的存在内存泄露问题？

3. java gc时的触发点是什么？在什么情况下会出现“CMS-concurrent-abortable-preclean-start]”这个问题？

4. 下面那几句话具体什么意思？

215.308: [CMS-concurrent-sweep-start]
215.419: [CMS-concurrent-sweep: 0.108/0.111 secs] [Times: user=0.14 sys=0.02, real=0.11 secs]
215.419: [CMS-concurrent-reset-start]
215.448: [CMS-concurrent-reset: 0.029/0.029 secs] [Times: user=0.04 sys=0.02, real=0.03 secs]

5. 如果程序不存在内存泄露的情况，在服务器运行一段时间之后，如果进行full gc，服务器占用内存是不是应该等于服务器刚刚重启后占用的内存？
( tomcat 6, spring+struts+hibernate，没有使用2级缓存，没有使用lazy加载，采用的是appfuse1.9的架构）

难道大家都没碰到过这个问题？

forEach应该没有内存问题：他暴露的变量只是放在request中，请求处理完了就释放了。

但是他有这两行代码

# _jspx_th_c_005fforEach_005f2.doFinally(); //在这里进行属性的清除 
#       _005fjspx_005ftagPool_005fc_005fforEach_0026_005fvar_005fitems.reuse(_jspx_th_c_005fforEach_005f2);

我怀疑在reuse之前 _jspx_th_c_005fforEach_005f2 没有执行release()来释放资源

CMS-concurrent-abortable-preclean-start　这个问题如果在你的机器非常频繁的出现，　那么只能说，　你的配置存在问题。　　这个东西的含义是，　并发收集可能导致应用马上内存就不够了，　直接放弃并发，　使用老的收集机制。　另外，　我不知道你的jdk是什么版本的，　如果是１。５。０９之前的版本，　ＯＫ，　兄弟恭喜你，你的ＣＭＳ的收集机制导致了更严重的收集问题。　这个是ＳＵＮ　ＪＤＫ的ＢＵＧ。　ＯＬＤ被占用２０％就会导致ＣＭＳ启动，　导致ＳＴＯＰ　ＷＯＬＲＤ的时间被站用过多。

如果一个没有内存泄露的程序，　一般运行一段时间后，内存据差不多稳定了，　基本是ＦＧＣ结束后占用的大小。　

如果你内存是使用比较多，　那么需要仔细调节内存参数。不知道你现在确实需要多少内存。