我们已经找到了造成此问题的原因。最新的JDBC驱动程序9.2-100x中setQueryTimeout（）的错误实现解释了这一点。如果您手动打开/关闭连接，则可能不会发生这种情况，但通常是在适当位置建立连接池并将
autocommit 设置为 false的情况下发生的
。在这种情况下，应使用非零值调用setQueryTimeout（）（例如，使用Spring框架@Transactional（timeout =
xxx）批注）。
事实证明，只要在语句执行过程中引发SQL异常，取消计时器就不会被取消并保持活动状态（这就是实现方式）。由于存在池，后面的连接不会关闭，而是返回到池中。稍后，当取消计时器触发时，它会随机取消当前与此计时器创建时所使用的连接相关的查询。目前，这是一个完全不同的查询，它解释了随机性的影响。
建议的解决方法是放弃setQueryTimeout（），改用PostgreSQL配置（statement_timeout）。它没有提供相同级别的灵活性，但至少始终有效。
