我们有一个使用 Tomcat 6 和 MySQL 5.0 的 Java Spring MVC 2.5 应用程序。我们有一个奇怪的场景，无论出于何种原因，c3p0 连接池中使用的连接数量开始失控并最终导致 tomcat 宕机。
我们通过 JMX 监控 c3p0 连接池，大多数时候，几乎没有使用连接。当这种螺旋式上升的情况发生时，我们的 tomcat 连接池会达到最大值，并且 apache 开始排队线程。
在螺旋式场景中，数据库负载较低，不会出现任何错误或任何明显的不良情况。
开始没有关于如何检测此问题的想法。当情况已经失控并且不确定我如何在它失控之前抓住它时，我认为做一个 tomcat 堆栈转储对我没有任何好处。
我们还使用 Terracotta，根据日志我不相信它在做任何奇怪的事情。
任何想法将不胜感激！
干杯!
你在某个地方泄漏了连接。当您从会话工厂显式检索 Hibernate 会话时，可能会发生这种情况，而不是获取与进程内事务关联的连接（不记得确切的方法名称）。
C3P0 将允许您使用两个配置选项来调试这种情况（以下是从文档中复制的，它们是下载包的一部分）：
unreturnedConnectionTimeout 定义连接可以保持签出状态的限制（以秒为单位）。如果设置为 nozero 值，则未返回的、已签出的超过此限制的连接将被立即销毁，然后在池中替换
将 debugUnreturnedConnectionStackTraces 设置为 true，则每次签出连接时都会捕获堆栈跟踪。每当未返回的连接超时时，将打印该堆栈跟踪，显示未及时签入的连接被签出的位置。debugUnreturnedConnectionStackTraces 仅用于调试，因为捕获堆栈跟踪会减慢连接签出速度