因此，直接的问题是连接池试图获取新的连接，但是试图获取这些任务的任务冻结了很长一段时间，以至于c3p0决定必须将任务进行死锁，然后丢弃并替换线程池。后来，线程池被挂在空闲连接测试任务上。
通常，“挂起”任务看起来像第一个“
Pool线程堆栈跟踪：”下方的第二个Thread：执行无法完成的网络IO。您的情况很奇怪，因为三个线程中的两个没有卡在IO中。他们刚刚开始做任何事情，但他们还没有活着。然后，您会遇到OutOfMemoryError，并且在空闲连接测试任务上也得到另一个APPARENT
DEADLOCK，看起来也应该很活跃。
也许您的应用程序与某种资源限制非常接近，导致资源运行缓慢。直接地，您可能会增加此应用程序可用的内存量（或修改它以减少内存占用）。在线程池第二次尝试刷新并重新创建挂起的线程时，您会遇到一个OOME，这不是由它直接引起的，而很可能是由不断增长的线程占用空间引起的。（在您的日志中，以前是否有很多这样的APPARENT
DEADLOCK
？？如果您强制执行JVM线程转储，您是否看到
com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread周围有很多实例，仍然挂在旧实例上，未完成任务？
一些一般性的评论：如果您的负载不超过5个并发查询，为什么会有这么大的资源池？为什么不
min_size5欧元，最多10欧元？对于池中允许的连接数，您的max_statements设置太小了。我会完全忽略这一点，直到您一切顺利为止。然后，为了获得更好的性能，您可以根据需要设置更直接的原因
maxStatementsPerConnection。
通常，您需要通过增加资源，减少其占用空间或解决可能导致其资源占用增加到极限的任何问题，使应用程序的占用空间（内存？线程？）远低于分配给它的资源。首先，使池变小，可用内存变大，然后将池配置成更小。
