HikariCP连接池-“活动”-如何调试？

Question

此刻我被困住的一点是调试处于“活动”状态的连接，以及它们正在做什么或它们当前被困的原因。

当我运行“10个同时用户”时，它基本上可以转换成2或3倍于此的查询，因此，当我打开HikariCP调试日志时，它会挂在类似的位置-(total=10,active=10,idle=0,waiting=2)上，而“active”连接并没有真正释放连接，这正是我试图找出的原因，因为查询相当简单，表本身只有4个字段（包括主键）。

HikariCP人员的最佳实践通常也是，增加连接池不是实现伸缩的正确第一步。

如果我确实将连接池的大小增加到20，那么对于10个同时/并发的用户来说，情况就开始正常了，但我认为这并不是问题的根本原因/解决方案。

是否有任何方法可以记录Hibernate或Postgres消息，以帮助了解这些“活动”连接正在等待什么，以及为什么即使在我将等待时间增加到很长时间后连接仍未释放？

如果是连接泄漏（当泄漏检测阈值降低到较低值（例如30秒）时会报告），那么如何判断是Hibernate造成了连接泄漏，还是其他原因造成的？

在@Brettw的帮助之后更新，当连接耗尽并指向连接泄漏的方向时，我进行了线程转储。HikariCP问题板上的线程--https://github.com/brettwooldridge/HikariCP/issues/1030#issuecomment-347632771-，它指向Hibernate没有关闭连接，然后将我指向https://jira.spring.io/browse/spr-14548，它讨论了设置Hibernate的连接关闭模式，因为默认模式保持连接的时间太长。在设置spring.jpa.properties.hibernate.connection.handling_mode=delayed_acception_and_release_after_transaction之后，连接池工作得很好。

此外，这里提出的观点--https://github.com/brettwooldridge/hikaricp/issues/612#issuecomment-209839908是正确的--连接泄漏不应该被池掩盖。

Answer 1

这听起来像是在数据库中遇到了真正的死锁。应该有一种方法来查询PostgreSQL当前活动查询和当前锁状态。你得谷歌一下。

另外，我会尝试一个简单的线程转储来查看所有线程被阻塞的位置。可能是代码级同步死锁。

• 如果getconnection()上的所有线程都被阻塞，这就是泄漏。
• 根据每个线程的stacktrace，如果驱动程序中的所有线程都关闭，则为数据库死锁。
• 如果在应用程序代码中等待锁的所有线程都被阻塞，那么就会出现同步死锁--在代码的不同部分可能会出现两个获取顺序相反的锁。