Java+SpringBoot多租户应用连接池异常及Finalizer连接问题排查咨询

问题背景 #

我们的Java+SpringBoot多租户应用出现数据库连接数达上限的问题，报错Unable to acquire JDBC Connection。调大连接池规模后问题暂时解决，但PostgreSQL数据库中多数连接处于闲置状态，应用本不应需要如此多的连接。

疑问解答 #

1. 连接池重复实例是否源于多线程问题？ #

这个判断有合理性，但不能直接定论。多线程环境下如果连接池初始化逻辑未做线程安全控制（比如未加锁、使用非线程安全的单例实现），确实可能导致重复创建连接池实例。但也存在其他可能：比如多租户配置错误导致每个租户重复初始化连接池、Spring容器中存在重复的连接池Bean定义、第三方组件（如某些多租户框架）未正确复用连接池等。

2. “referent in Finalizer”状态的PGConnection对象含义 #

是的，这类对象已被标记为待垃圾回收，但Finalizer线程尚未完成对它们的清理。通常情况下，JDBC连接应该通过close()方法主动释放回连接池，而非依赖Finalizer。大量连接进入Finalizer队列，说明存在连接未被正确关闭的情况——Finalizer线程的处理速度远慢于主动释放，会导致连接长期占用数据库资源，最终引发连接耗尽。

后续排查方向 #

• 连接池初始化逻辑审计
  • 检查连接池Bean的定义：是否存在重复的@Bean注解、是否在多线程初始化场景（如多租户上下文加载）中未做单例保证
  • 排查多租户配置逻辑：是否每个租户都错误创建了独立连接池，而非复用或按租户合理分配连接池资源
  • 验证线程安全：在高并发场景下模拟连接池初始化，观察是否会创建多个实例
• 连接泄漏排查
  • 检查代码中JDBC连接的使用：是否存在未在try-with-resources中管理连接、未调用close()的情况
  • 开启连接池的泄漏检测功能（如HikariCP的leakDetectionThreshold），定位未正确释放连接的代码路径
  • 分析Finalizer队列中的连接对象引用链，找到持有连接的残留对象，定位泄漏点
• 数据库连接状态分析
  • 查询PostgreSQL的pg_stat_activity视图，统计闲置连接的来源（应用进程、连接池实例）
  • 对比连接池配置的最大连接数与实际数据库中的连接数，确认是否存在连接池实例超额创建的情况
• Spring容器与多租户框架校验
  • 检查Spring容器中连接池Bean的数量，确认是否与堆转储中发现的32个实例匹配
  • 如果使用了多租户框架（如MultiTenantConnectionProvider），排查其连接池复用逻辑是否存在缺陷

潜在问题原因 #

• 连接池初始化线程不安全：单例模式实现错误（如双重检查锁定未正确加volatile）、多线程同时触发初始化逻辑，导致创建多个连接池实例
• 连接泄漏：代码中未主动关闭JDBC连接，依赖Finalizer回收，导致连接长期占用数据库资源
• 多租户配置错误：多租户逻辑未合理复用连接池，为每个租户创建独立连接池，导致总连接数激增
• 连接池配置不合理：闲置连接超时时间设置过长，导致闲置连接无法被及时回收；或者连接池最大连接数设置过大，叠加多实例后超出数据库上限
• Finalizer线程阻塞：Finalizer线程因某些原因（如死锁、长时间执行的finalize方法）无法及时清理连接对象，导致连接堆积

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