Tomcat中的Java Web应用会定期冻结

Question

运行Tomcat（7.0.28）的Java
Web应用程序会定期变得无响应。我希望对可能的罪魁祸首（同步？）提出一些建议，以及一些建议的工具，以收集有关崩溃期间发生的事情的更多信息。我积累的一些事实：

• 当Web应用程序冻结时，tomcat继续将请求线程送入应用程序，但该应用程序不会释放它们。线程池已满（当前为250），然后后续请求立即失败。在正常操作期间，活动线程永远不会超过2或3。

• 发生问题时，不会在我们的任何tomcat或Web应用程序日志中记录任何类型的错误或异常。

• 通过tomcat管理Web应用程序在我们的应用程序上执行“停止”，然后执行“开始”，将立即解决此问题（直到今天）。

• 最近的频率是每天两次或三次，尽管今天情况更糟，可能是二十次，有时还不能立即恢复。

• 仅在工作时间内出现问题

• 在我们的登台系统上不会发生此问题

• 发生问题时，服务器上的处理器和内存使用率保持不变（并且相当低）。Tomcat报告大量可用内存。

• 发生问题时，Tomcat继续保持响应。管理网络应用程序运行良好，tomcat继续将请求发送到我们的应用程序中，直到池中的所有线程都被填满。

• 发生问题时，我们的数据库服务器将保持响应状态。我们使用Spring框架进行数据访问和注入。

• 使用率很高时通常会出现问题，但是使用率绝不会出现异常高的峰值。

• 问题历史记录：大约一年半以前发生了类似的事情。在对许多服务器配置和代码进行更改之后，该问题消失了直到大约一个月前。在过去的几周中，这种情况发生的频率更高，平均每天发生2到3次，有时连续几次。

• 我今天确定了一些服务器代码，这些代码可能不是线程安全的，为此我进行了修复，但是问题仍然在发生（尽管不那么频繁）。这是非线程安全代码可能导致的那种问题吗？

更新：
有几篇文章建议数据库连接池用尽，我对此进行了一些搜索，发现了这个另一个Stackoverflow问题，它可以解释我遇到的几乎所有问题。

显然，Apache的BasicDataSource实现中的maxActive和maxIdle连接的默认值分别为8。而且，maxWait设置为-1，因此当池耗尽且有新的连接请求进入时，它将永远等待而无需记录任何内容。有点例外。我仍然要等待这个问题再次发生，并在JVM上执行jstack
dump，以便我可以分析该信息，但是看起来这就是问题所在。它唯一无法解释的是为什么应用有时无法从此问题中恢复。我想这些请求有时会堆积起来，一旦落后，就永远无法追上。

更新二： 我在崩溃期间运行了一个jstack，发现以下内容约有250个（最大线程）：

"http-nio-443-exec-294" daemon prio=10 tid=0x00002aaabd4ed800 nid=0x5a5d in Object.wait() [0x00000000579e2000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:485)
        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1118)
        - locked <0x0000000743116b30> (a org.apache.commons.pool.impl.GenericObjectPool$Latch)
        at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
        at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
        at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111)
        at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77)
        at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:573)
        at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:637)
        at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:666)
        at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:674)
        at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:718)

在我未经训练的眼睛看来，这是相当确定的。看起来数据库连接池已达到顶峰。我配置了三秒的maxWait，而没有修改maxActive和maxIdle只是为了确保我们开始看到池已满时记录的异常。然后，我将这些值设置为适当的值并进行监视。

更新III： 配置maxWait之后，我开始按预期在日志中看到这些：

 org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error Timeout waiting for idle object
        at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:114)
        at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
        at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111)
        at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77)

我已经将maxActive设置为-1（无限），并将maxIdle设置为10。我将监视一会儿，但是我猜这是问题的结尾。

Answer 1

根据经验，您可能需要查看 数据库连接池的
实现。可能您的数据库具有足够的容量，但是应用程序中的连接池仅限于少数几个连接。我不记得详细信息，但我似乎还记得有一个类似的问题，这是我改用BoneCP的原因之一，在负载测试下，我发现它非常快速且可靠。

在尝试了下面建议的调试之后，请尝试增加池中可用的连接数，看看是否有影响。

我今天确定了一些服务器代码，这些代码可能不是线程安全的，为此我进行了修复，但是问题仍然在发生（尽管不那么频繁）。这是非线程安全代码可能导致的那种问题吗？

这取决于您所说的线程安全。在我看来，您的应用程序正在导致线程死锁。您可能希望使用配置为允许调试器连接的JVM运行生产环境，然后使用JVisualVM，JConsole或其他分析工具（YourKit是出色的IMO）来窥视所拥有的线程以及它们的线程。在等待。