我在 Tomcat 7/Java 7 上运行 Java EE-ish Web 应用程序（Hibernate 4+Spring+Quartz+JSF+Facelets+Richfaces）的几个（大约 15 个）实例时遇到了一个奇怪但严重的问题。
系统运行得很好，但是在经过很长一段时间后，应用程序的所有实例同时突然出现响应时间增加的问题。基本上该应用程序仍然可以工作，但响应时间大约高出三倍。
这是两个图表，显示了两个示例实例的两个特定短工作流/操作（登录、研讨会访问列表、ajax-refresh 此列表、注销；下一行只是 ajax 刷新的请求时间）的响应时间应用程序：
如您所见，应用程序的两个实例同时“爆炸”并保持缓慢。重启服务器后一切恢复正常。应用程序的所有实例同时“爆炸”。
我们将会话数据存储到数据库中，并将其用于集群。我们检查了会话大小和数量，两者都相当低（这意味着在具有其他应用程序的其他服务器上，我们有时会拥有更大和更多的会话）。集群中的另一个 Tomcat 通常会快速保持几个小时，并且在这个随机的时间之后它也“死亡”。我们用 jconsole 检查了堆大小，主堆保持在 2.5 到 1 GB 大小之间，db 连接池基本上都是空闲连接，还有线程池。最大堆大小为 5 GB，还有大量可用的 perm gen 空间。负载不是特别高；主 CPU 上只有大约 5% 的负载。服务器不交换。这也不是硬件问题，因为我们另外将应用程序部署到问题仍然存在的 VM 上。
我不知道在哪里看了，我没有想法。有人知道在哪里看吗？
2013-02-21 更新：新数据！
我向应用程序添加了另外两个时序跟踪。至于测量：监控系统调用一个执行两个任务的servlet，测量服务器上每个任务的执行时间，并将所用时间写为响应。这些值由监控系统记录。
我有几个有趣的新事实：应用程序的热重新部署导致当前 Tomcat 上的单个实例发疯。这似乎也会影响原始 CPU 计算性能（见下文）。这种个体语境爆炸不同于随机发生的整体语境爆炸。
现在来看一些数据：
首先是单行：
- 浅蓝色是小工作流的总执行时间（详情见上文），在客户端测量
- 红色是浅蓝色的“一部分”，是执行该工作流程的特殊步骤所花费的时间，在客户端上测量
- 深蓝色在应用程序中测量，包括通过 Hibernate 从数据库读取实体列表并迭代该列表，获取惰性集合和惰性实体。
- Green 是一个使用浮点和整数运算的小型 CPU 基准测试。据我所知，没有对象分配，所以没有垃圾。
现在来看爆炸的各个阶段：我用三个黑点标记了每张图像。第一个是或多或少只有一个应用程序实例中的“小”爆炸——在 Inst1 中它会跳跃（尤其是在红线中可见），而 Inst2 下面或多或少保持平静。
在这个小爆炸之后，发生了“大爆炸”，并且该 Tomcat 上的所有应用程序实例都爆炸了（第 2 个点）。请注意，这种爆炸会影响所有高级操作（请求处理、数据库访问），但不会影响CPU 基准测试。它在两个系统中都保持在低位。
之后，我通过触摸 context.xml 文件热重新部署了 Inst1。正如我之前所说，这个实例从爆炸到现在完全被摧毁（浅蓝色线不在图表中 - 它大约在 18 秒处）。注意 a) 这种重新部署根本不影响 Inst2 和 b) Inst1 的原始 DB 访问也没有受到影响 - 但是 CPU似乎突然变得更慢了！. 这太疯狂了，我说。
更新更新 当应用程序被取消部署时，Tomcat 的防泄漏监听器不会抱怨陈旧的 ThreadLocals 或 Threads。显然似乎存在一些清理问题（我认为这与大爆炸没有直接关系），但 Tomcat 对我没有任何提示。
2013-02-25 更新：应用环境和石英时间表
应用环境不是很复杂。除了网络组件（我不太了解这些），基本上还有一个应用程序服务器（Linux）和两个数据库服务器（MySQL 5 和 MSSQL 2008）。主要负载在 MSSQL 服务器上，另一个仅用作存储会话的地方。
应用程序服务器运行 Apache 作为两个 Tomcat 之间的负载平衡器。所以我们有两个 JVM 在同一个硬件上运行（两个 Tomcat实例）。我们使用这种配置并不是为了真正平衡负载，因为应用程序服务器能够很好地运行应用程序（多年来一直如此），而是在不停机的情况下启用小型应用程序更新。有问题的 Web 应用程序被部署为不同客户的单独上下文，每个 Tomcat 大约有 15 个上下文。（我似乎在我的帖子中混淆了“实例”和“上下文” - 在办公室里，它们经常被用作同义词，我们通常神奇地知道同事在说什么。我的错，我真的很抱歉。）
为了用更好的措辞澄清这种情况：我发布的图表显示了同一应用程序在同一 JVM 上的两个不同上下文的响应时间。大爆炸会影响一个 JVM 上的所有上下文，但不会在另一个 JVM 上发生（顺便说一句，Tomcat 爆炸的顺序是随机的）。热重新部署后，一个 Tomcat 实例上的一个上下文变得疯狂（具有所有有趣的副作用，例如该上下文的 CPU 似乎较慢）。
系统的整体负载相当低。它是一个内部核心业务相关软件，同时拥有大约 30 个活跃用户。特定于应用程序的请求（服务器接触）目前约为每分钟 130 个。单个请求的数量很少，但请求本身通常需要对数据库进行数百次选择，因此它们相当昂贵。但通常一切都是完全可以接受的。该应用程序也不会创建大型无限缓存 - 一些查找数据被缓存，但只缓存很短的时间。
上面我写道，能够运行应用程序的服务器可以正常运行几年。我知道找到问题的最佳方法是准确找出第一次出现问题的时间，并查看在此时间范围内发生了什么变化（在应用程序本身、相关的库或基础设施中），但问题是我们不知道问题是什么时候出现的。让我们称之为次优（在不存在的意义上）应用程序监控......：-/
我们排除了某些方面，但该应用程序在过去几个月中已多次更新，因此我们不能简单地部署旧版本。最大的更新不是功能更改是从 JSP 到 Facelets 的转换。但是，“某事”一定是所有问题的原因，但我不知道为什么 Facelets 会影响纯 DB 查询时间。
石英
至于 Quartz 时间表：总共有 8 个作业。它们中的大多数每天只运行一次，并且与大容量数据同步有关（绝对不是“大数据”中的“大”；这只是普通用户在日常工作中看到的更多）。但是，这些工作当然是在夜间运行，而问题发生在白天。我在这里省略了详细的工作清单（如果有帮助，我当然可以提供更多细节）。作业的源代码在过去几个月中没有更改。我已经检查了爆炸是否与工作一致——但结果充其量是不确定的。我实际上会说它们没有对齐，但是由于每分钟都有几项工作在运行，所以我还不能排除它。在我看来，每分钟运行的实际工作重量都很轻，
但是，我目前正在启用单个作业执行的日志记录，以便我可以准确地看到每个单个作业执行的开始和结束时间戳。也许这提供了更多的洞察力。
2013-02-28 更新：JSF 阶段和时序
我手动向应用程序添加了一个 JSF phae 侦听器。我执行了一个示例调用（ajax 刷新），这就是我所得到的（左：正常运行的 Tomcat 实例，右：Big Bang 之后的 Tomcat 实例 - 这些数字几乎同时从两个 Tomcat 中获取，以毫秒为单位）：
- RESTORE_VIEW：17 对 46
- APPLY_REQUEST_VALUES：170 与 486
- PROCESS_VALIDATIONS：78 对 321
- UPDATE_MODEL_VALUES：75 对 307
- RENDER_RESPONSE：1059 与 4162
ajax 刷新本身属于搜索表单及其搜索结果。在应用程序的最外层请求过滤器和 web 流开始工作之间还有另一个延迟：有一个FlowExecutionListenerAdapter用于测量 web 流某些阶段所花费的时间。此侦听器报告“已提交请求”（据我所知是第一个 Web 流事件）的 1405 毫秒，而未爆炸的 Tomcat 上的完整请求总共需要 1632 毫秒，因此我估计大约有 200 毫秒的开销。
但是在爆炸的 Tomcat 上，它报告的请求提交时间为 5332 毫秒（这意味着所有 JSF 阶段都发生在这 5 秒内），而总请求持续时间为 7105 毫秒，因此对于提交的 Web 流请求之外的所有内容，我们最多有 2 秒的开销.
在我的测量过滤器下方，过滤器链包含一个org.ajax4jsf.webapp.BaseFilter，然后调用 Spring servlet。
2013-06-05 更新：最近几周发生的所有事情
一个小而相当晚的更新......应用程序性能在一段时间后仍然很糟糕，并且行为仍然不稳定。剖析还没有太大帮助，它只是产生了大量难以剖析的数据。（尝试在生产系统上查看性能数据或配置文件...叹息）我们进行了几次测试（删除软件的某些部分，取消部署其他应用程序等），实际上进行了一些影响整个应用程序的改进。我们的默认刷新模式EntityManager是AUTO在视图渲染期间发出大量的获取和选择，始终包括检查是否需要刷新。
所以我们构建了一个 JSF 阶段监听器，将刷新模式设置为COMMITduring RENDER_RESPONSE。这大大提高了整体性能并且似乎在一定程度上缓解了这些问题。
然而，我们的应用程序监控在某些 tomcat 实例的某些上下文中不断产生完全疯狂的结果和性能。就像一个应该在一秒钟内完成的动作（实际上是在部署后完成的），而现在需要超过四秒钟。（这些数字由浏览器中的手动计时支持，因此导致问题的不是监控）。
例如看下图：
此图显示了两个运行相同上下文的 tomcat 实例（意味着相同的数据库、相同的配置、相同的 jar）。同样，蓝线是纯 DB 读取操作（获取实体列表，迭代它们，延迟获取集合和相关数据）所花费的时间。绿松石色和红线分别通过渲染几个视图和进行 ajax 刷新来测量。由绿松石色和红色的两个请求呈现的数据与蓝线查询的数据基本相同。
现在在实例 1（右）的 0700 左右，纯 DB 时间大幅增加，这似乎也影响了实际的渲染响应时间，但仅在 tomcat 1 上。Tomcat 0 基本上不受此影响，因此它不是由 DB 引起的服务器或网络，两个 tomcat 都运行在相同的物理硬件上。它必须是 Java 域中的软件问题。
在我上次的测试中，我发现了一些有趣的事情：所有响应都包含标题“X-Powered-By: JSF/1.2, JSF/1.2”。有些（WebFlow 产生的重定向响应）甚至在其中包含 3 次“JSF/1.2”。
我追踪了设置这些标头的代码部分，第一次设置此标头时，它是由此堆栈引起的：
... at org.ajax4jsf.webapp.FilterServletResponseWrapper.addHeader(FilterServletResponseWrapper.java:384)
at com.sun.faces.context.ExternalContextImpl.<init>(ExternalContextImpl.java:131)
at com.sun.faces.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:108)
at org.springframework.faces.webflow.FlowFacesContext.newInstance(FlowFacesContext.java:81)
at org.springframework.faces.webflow.FlowFacesContextLifecycleListener.requestSubmitted(FlowFacesContextLifecycleListener.java:37)
at org.springframework.webflow.engine.impl.FlowExecutionListeners.fireRequestSubmitted(FlowExecutionListeners.java:89)
at org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:255)
at org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:169)
at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:183)
at org.springframework.webflow.mvc.servlet.FlowController.handleRequest(FlowController.java:174)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:925)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:920)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:827)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
... several thousands ;) more
此标头第二次由
at org.ajax4jsf.webapp.FilterServletResponseWrapper.addHeader(FilterServletResponseWrapper.java:384)
at com.sun.faces.context.ExternalContextImpl.<init>(ExternalContextImpl.java:131)
at com.sun.faces.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:108)
at org.springframework.faces.webflow.FacesContextHelper.getFacesContext(FacesContextHelper.java:46)
at org.springframework.faces.richfaces.RichFacesAjaxHandler.isAjaxRequestInternal(RichFacesAjaxHandler.java:55)
at org.springframework.js.ajax.AbstractAjaxHandler.isAjaxRequest(AbstractAjaxHandler.java:19)
at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.createServletExternalContext(FlowHandlerAdapter.java:216)
at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:182)
at org.springframework.webflow.mvc.servlet.FlowController.handleRequest(FlowController.java:174)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:925)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:920)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:827)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
我不知道这是否表明存在问题，但我没有注意到在我们的任何服务器上运行的其他应用程序，所以这也可以提供一些提示。我真的不知道该框架代码在做什么（诚然我还没有深入研究它）......也许有人有想法？还是我陷入了死胡同？
附录
我的 CPU 基准代码包含一个循环，该循环计算 Math.tan 并使用结果值修改 servlet 实例上的某些字段（那里没有 volatile/同步），然后执行几个原始整数计算。这不是很复杂，我知道，但是……它似乎在图表中显示了一些东西，但是我不确定它显示了什么。我进行字段更新以防止 HotSpot 优化掉我所有宝贵的代码；）
long time2 = System.nanoTime();
for (int i = 0; i < 5000000; i++) {
double tan = Math.tan(i);
if (tan < 0) {
this.l1++;
} else {
this.l2++;
}
}
for (int i = 1; i < 7500; i++) {
int n = i;
while (n != 1) {
this.steps++;
if (n % 2 == 0) {
n /= 2;
} else {
n = n * 3 + 1;
}
}
}
// This execution time is written to the client.
time2 = System.nanoTime() - time2;
