WebLogic连接池忽略最大容量限制问题求助

我之前在维护WebLogic 12.1.3.0.0 + Oracle + Hibernate的环境时，碰到过几乎一模一样的连接池异常——运行一段时间后数据源无视Maximum Capacity设置，重启或重建数据源只能临时解决。结合官方文档和实际排查经验，给你几个能定位根本问题的方向和解决方案：

一、先核对WebLogic数据源的核心配置 #

• 语句缓存与连接占用：检查Statement Cache Size，如果设置得过大（比如超过200），会导致连接被绑定的语句占用过长时间，间接让可用连接耗尽，看起来像是突破了最大容量。建议根据业务量调整到50-100之间，同时确保Statement Cache Type设置为LRU（最近最少使用）。
• 连接回收与测试配置：确认Inactive Connection Timeout是否开启（建议设为300秒），Test Frequency设为60秒，并且勾选Test Connections On Reserve，测试语句用SELECT 1 FROM DUAL（Oracle环境专属）。如果连接长时间闲置却没被回收，加上测试不及时，会导致连接池里的有效连接不足，出现“超容”假象。

二、Hibernate代码层面的连接泄漏排查 #

• 连接释放模式检查：查看Hibernate配置中的connection.release_mode，如果是on_close，连接会直到Session关闭才释放。如果代码里存在Session未正确关闭的情况（比如异常时没走finally块），会造成连接泄漏，最终把连接池耗满。建议改成auto或after_transaction，让连接在事务结束后自动释放。
• 启用连接泄漏检测：可以通过Hibernate的日志或WebLogic控制台监控来排查泄漏。在WebLogic Console的数据源 -> 监控页面，查看Active Connections Current Count和Leaked Connections指标，如果泄漏数持续增长，那就是代码层面的问题，需要结合线程栈追踪未关闭的Session。

三、WebLogic 12.1.3的已知BUG与补丁修复 #

• 这个版本有几个明确的连接池相关BUG，比如BUG 19565766（特定场景下连接池无法正确回收闲置连接）、BUG 20872785（关闭Pin-to-Thread后连接池管理逻辑异常）。这些问题都在后续的PSU（补丁集更新）中被修复了，建议升级到最新的12.1.3 PSU版本（比如12.1.3.0.230418），这是最彻底的根本解决方案。

四、自定义监控辅助定位 #

• 如果暂时无法打补丁，可以写个简单的JMX监控脚本，定时获取数据源的ActiveConnectionsCurrentCount和MaxCapacity，当连接数接近阈值时，触发告警并抓取当时的线程栈。通过线程栈可以看到哪些线程在占用连接，进而定位到对应的业务代码或框架问题。

五、临时优化方案（非根本解决） #

• 若补丁还在测试中，可临时调整数据源配置：把Initial Capacity设为和Maximum Capacity一致，同时开启Shrink Frequency（设为300秒），让连接池定期收缩到初始容量，减少泄漏连接的累积影响。但这只是缓兵之计，还是要尽快推进补丁或代码修复。

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