好的，因此在分析了线程转储之后，我们意识到某种程度的线程正在等待c3p0库的 awaitAvailable
（）方法，该方法在我们的应用程序中管理数据库连接。我们发现了一个讨论，有人建议将c3p0库（从0.9.1.2升级到0.9.2），因为当从池中检出大量并发连接时，旧库会出现此问题，签入后连接计数器值仍然膨胀，因此不允许签出新的连接，导致进程永久等待连接（我们的签出超时=
0）。
但是，即使在升级库之后，我们仍然会遇到此问题，因此我们使用 debugUnreturnedConnectionStackTraces
属性来查看连接发生了什么以及为什么它们不可用。经过一天的日志记录，我们意识到我们的代码正在泄漏由c3p0管理的数据库连接。在我们的代码中，很少有流量在关闭finally块中的实体管理器之前没有在catch块中专门调用rollback（），因此，在出现异常的情况下，连接不会回到池中并且异常发生的频率很高（大于大小）超时间隔内的池数），则所有其他进程线程将堆积以建立连接。
由于该代码是固定的，因此我们没有看到任何此类线程堆积问题。
