java - Sun Web Server 7 服务 .jsp - Eden 空间行为 - 可能存在内存泄漏

Question

我的公司最近迁移到 Alfresco 作为内容管理解决方案。由于某些内容是动态的(包含在另一个 .jsp 中的 .jsp 文件读取从 Alfresco 发布为 xml 的站点地图 并将结果缓存 24 小时)生成的文件为 .jsp，并通过我们的 Sun Web Server 7 servlet 容器进行 rsync 和服务。

每个页面都有一个页眉、一个菜单和一个页脚 使用 jsp:include 运行时指令。我的理解是，当第一次请求 index.jsp 时，将会有许多已编译的 jsps，例如index.class、header.class、 menu.class 和 footer.class。要求是让这些内容编译一次，servlet 容器每 x 秒检查任何源 jsps(由 Alfresco 推出)的修改。

Web 服务器本身已配置 (default-web.xml)，可按照 Sun 文档的建议使用以下参数进行生产:

<init-param>
  <param-name>development</param-name>
  <param-value>false</param-value>
</init-param>
<init-param>
  <param-name>checkInterval</param-name>
  <param-value>0</param-value>
</init-param>   
  <init-param>
  <param-name>fork</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
  <param-name>mappedfile</param-name>
  <param-value>false</param-value>
</init-param>
<init-param>
  <param-name>suppressSmap</param-name>
  <param-value>true</param-value>
</init-param>
<init-param>
  <param-name>classdebuginfo</param-name>
  <param-value>false</param-value>
</init-param>
<init-param>
  <param-name>trimSpaces</param-name>
  <param-value>true</param-value>
</init-param>

请注意，checkInterval 参数应设置为 60，但这样做会导致 Web 服务器无法启动(我一直无法弄清楚原因)。不幸的解决方法是然后将 development 设置为 true，这是我想避免的。

servlet 容器配置有以下 JVM 设置(同样是 Sun 文档推荐的):

-server -Xrs -Xmx2048m -Xms2048m -Xmn2024m -XX:+AggressiveHeap -XX:LargePageSizeInBytes=256m -XX:+UseParallelOldGC -XX:+UseParallelGC -XX:ParallelGCThreads=8 -XX:+DisableExplicitGC

在性能测试过程中，我们发现 Eden 空间经常飙升至 2GB(静态内容的总大小约为 200mb，而我们的测试是针对少数页面进行的)。结果产生了许多小型 Collection ；将对象快速插入 Tenured 空间，并且它永远不会真正恢复，导致大量频繁的 Full GC (幸存者空间也从 90mb 缩小到 2 字节，我只能假设是伊甸园空间声称它是自己的 - 谁能确认？)。这是我们最大的问号；我们的开发人员都没有 认为这是正常行为，但我们无法解释该内存的去向。

我们看到的另一个问题是线程计数。每个 http 请求都会在 servlet 中产生一个新线程，我希望它与负载成正比(我也认为创建了一个新线程)在运行时执行 jsp:include 时，也会在每个 servlet 中(已编译的父 jsp 中的 RequestDispatcher.include())。然而，一旦每个请求得到服务，线程就会终止，并在其位置生成一个新线程。这是一个正确的假设吗？无论负载如何，线程计数似乎都会停止并增长。

任何帮助将不胜感激。

Answer 1

堆使用图中的锯齿模式是正常的，并不表示存在内存泄漏。仅当锯齿波的下限随时间呈上升趋势时才表明存在内存泄漏。

但是，始终执行 Full GC 是一个问题，这可能表明存在存储泄漏。尝试使用内存分析器运行，看看是否可以发现泄漏的内容。

我有一种感觉，我知道可能是什么导致了泄漏。我认为您说过您正在动态生成 JSP。每次容器找到新的(或更新的)JSP 时，它都会生成 Java 类，编译这些类，然后加载字节码。如果您不小心，旧类/旧版本的类将保持可达性并发生泄漏。

<小时/>

我也不希望线程数随着负载而上升和下降。一个像样的 Web 容器将维护一个用于处理传入请求的线程池。线程池通常有一个固定的上限，这样请求 Storm 不会导致线程数量爆炸，从而导致资源占用和争用问题。