我们有一个查询需要3个小时才能完成。这不是问题。之前，调用此查询的代码部署在weblogic上，并使用后者自己的连接池管理器。
现在由于进程占用了大量内存，我们将这些代码拉出来并使其在自己的堆空间上运行。调用查询的请求是通过jms完成的。我还注意到我们使用的连接池管理器是dbcp使用其默认设置（max connections = 8，min connections = 0）。 jms客户端是多线程的。
当我们通过接口（TOAD）执行查询时，它只需要2秒钟，所以从这里我已经排除了“责备”数据库。
我想知道从这里可以采取哪些步骤来找到瓶颈。也许是连接池的东西？
答案 0 :(得分：3)
您应该使用VisualVM或线程转储等工具来检查您的线程在做什么。他们只是在等待一些IO操作完成吗？是否有一些不良同步的代码等待的时间比需要的长得多？甚至可能在三小时（或三小时一小时）超时后停止死锁？
答案 1 :(得分：1)
我发现总是值得回到最基本的Java性能工具：线程转储。有很多方法可以获得线程转储：
看看你的计划在做什么。定期服用。有一些工具可以帮助您查看大型线程转储，例如Thread Dump Analyzer或Samurai。
您还可以使用jconsole或Visual VM以交互方式查看此内容，但我认为阅读原始转储的良好人才将为您提供良好的服务。