使用ComboPooledDataSource时是否应采用try-with-resources语法？

你的调整完全不合理，反而会引发严重的连接泄漏问题

ComboPooledDataSource返回的Connection是池化代理类，调用close()方法并不是真的关闭物理连接，而是把连接归还到连接池，供后续请求复用。try-with-resources的作用就是自动调用close()，这正好符合连接池的使用规范，能确保连接用完后及时归还，避免连接泄漏。

如果改用普通try语句且不调用close()，连接会一直被当前线程占用，无法回到连接池。随着请求增多，池里的可用连接会被耗尽，最终导致新请求无法获取连接，抛出连接超时或池耗尽的异常。

至于你遇到的连接频繁建立的问题，根本原因不是try-with-resources，大概率是这些情况：

• 连接池配置不合理：比如minPoolSize（最小空闲连接数）设置过低，池里没有足够的空闲连接，每次请求都得新建物理连接
• 业务代码长时间占用连接：比如在获取连接后执行了耗时的IO操作、复杂计算，导致连接无法及时归还复用
• 连接池参数配置不当：比如连接超时时间设置过短，池里的连接被提前销毁，需要频繁重建

正确的处理方式：

• 保留try-with-resources的写法，这是连接池场景下的最佳实践
• 调整ComboPooledDataSource的配置：把minPoolSize设为合理值（比如根据业务并发量设置），确保池里始终有足够的空闲连接
• 优化业务代码：尽量缩短连接的持有时间，把非数据库操作（比如文件读写、远程调用）放到获取连接之前或归还之后
• 开启连接池的监控日志，查看连接的获取、归还、销毁记录，精准定位频繁创建连接的原因

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