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