长时运行事务触发PostgreSQL连接关闭PSQLException问题求助

咱们碰到的这个org.postgresql.util.PSQLException: This connection has been closed错误很典型——只在执行时长超过数分钟的长事务时出现，结合堆栈里Hibernate事务回滚失败的信息，核心原因基本是连接被提前回收了，不管是数据库本身、连接池还是中间件干的。下面一步步拆解排查和解决方法：

先理清楚可能的触发点 #

• PostgreSQL端的事务空闲超时：PostgreSQL有个idle_in_transaction_session_timeout参数，如果你的环境里把它设成了几分钟，那长事务要是中间有空闲（比如等外部接口响应、慢查询间隙），数据库会主动把这个连接关掉。
• 连接池的超时回收：不管是HikariCP、Druid还是其他连接池，都有maxLifetime、idleTimeout这类参数。要是连接被池子里回收了，Hibernate还拿着旧的连接引用，自然就报连接关闭的错。
• 中间件的断开机制：比如防火墙、负载均衡设备，会主动断开长时间空闲的连接，要是你的长事务刚好卡在空闲阶段，也会中招。

具体解决步骤 #

1. 先查数据库的超时配置 #

登录PostgreSQL执行这条SQL看看：

SHOW idle_in_transaction_session_timeout;
SHOW statement_timeout;

要是idle_in_transaction_session_timeout设的时间比你的长事务预期时长短，直接调大它——比如设成30分钟：SET idle_in_transaction_session_timeout = 1800000;，想要永久生效就改postgresql.conf文件。

2. 调整连接池的参数适配长事务 #

拿常用的HikariCP举例，这几个参数得注意：

• maxLifetime：设得比你的最长事务执行时间长，比如3600000（1小时），别让连接池在事务还没结束就把连接收走。
• idleTimeout：如果事务里会有空闲阶段，这个值也要大于事务里的最大空闲时长。
• connectionTimeout：适当调大，避免获取连接时超时。

3. 优化长事务的执行逻辑 #

能拆分的尽量拆分！比如事务里要是有调用第三方接口、读写大文件这类非数据库操作，把它们移到事务外面去——只把必须在事务内的数据库操作留着。这样既缩短了事务时长，也减少了连接被超时回收的概率。

4. 给Hibernate加连接有效性检测 #

在Hibernate配置里加上这俩参数，每次从连接池拿连接时先验证是不是活的：

hibernate.connection.testOnBorrow=true
hibernate.connection.validationQuery=SELECT 1

这样就能避免拿到已经被关闭的连接了。

验证方式 #

改完配置后，模拟一个比之前超时时间长的长事务（比如在事务里加个Thread.sleep(300000)模拟5分钟的耗时操作），看看还会不会报连接关闭的错误。

内容的提问来源于stack exchange，提问作者nilgun