我们有一个使用 Tomcat 6 和 MySQL 5.0 的 Java Spring MVC 2.5 应用程序。我们遇到了一个奇怪的场景，无论出于何种原因，c3p0 连接池中使用的连接数量开始急剧上升并失去控制，最终导致 tomcat 宕机。
我们通过 JMX 监控 c3p0 连接池，大多数时候，连接几乎没有被使用。当这种螺旋式上升的情况发生时，我们的 tomcat 连接池达到最大值并且 apache 开始排队线程。
在螺旋上升的场景中，数据库负载很低，没有出现任何错误或任何明显的不良情况。
开始没有关于如何检测此问题的想法。当情况已经失控并且不确定如何在失控之前捕获它时，我认为执行 tomcat 堆栈转储对我没有任何好处。
我们还使用 Terracotta，根据日志我认为它没有做任何奇怪的事情。
任何想法将不胜感激!
干杯!
最佳答案
某处你正在泄漏连接。当您从 session 工厂显式检索 Hibernate session ，而不是获取与进程内事务相关联的连接(不记得确切的方法名称)时，可能会发生这种情况。
C3P0 将允许您使用两个配置选项调试这种情况(以下是从文档中复制的，它是下载包的一部分):
unreturnedConnectionTimeout defines a limit (in seconds) to how long a Connection may remain checked out. If set to a nozero value, unreturned, checked-out Connections that exceed this limit will be summarily destroyed, and then replaced in the pool
set debugUnreturnedConnectionStackTraces to true, then a stack trace will be captured each time a Connection is checked-out. Whenever an unreturned Connection times out, that stack trace will be printed, revealing where a Connection was checked out that was not checked in promptly. debugUnreturnedConnectionStackTraces is intended to be used only for debugging, as capturing a stack trace can slow down Connection check-out
关于java - 如何检测tomcat连接池问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15644526/