本文介绍如何在 java 应用中根据配置的连接名称(如 "current")智能复用

已有数据库连接,避免重复创建 datasource 实例,提升性能并减少资源开销。核心思路是引入连接缓存机制,按需获取或复用连接。
在实际开发中,尤其在多数据源 XML 配置驱动的查询场景下,频繁调用 DataSource.getConnection() 可能导致连接泄漏、资源耗尽或性能下降。你当前的代码每次执行 searchQuery() 都会重新获取 DataSource 并创建新连接,即使多个查询共用同一逻辑连接名(如 "current"),也未做去重或复用处理。
✅ 推荐方案:连接缓存 + 懒加载
使用 ConcurrentHashMap 缓存已建立的活跃连接,以连接名称为 key。每次查询前先检查缓存中是否存在对应名称的可用连接;若存在且未关闭,则直接复用;否则新建并缓存。注意:Connection 不可跨线程共享,且必须确保线程安全与及时释放。
以下是优化后的关键代码示例(含资源管理与异常防护):
private final Map connectionCache = new ConcurrentHashMap<>();
private final Object cacheLock = new Object();
public List
⚠️ 重要注意事项:
-
连接生命周期管理:缓存的 Connection 需配合应用上下文生命周期(如 Spring 的 @PreDestroy 或自定义连接清理器)定期校验并清除失效连接,防止 stale connection 积累;
-
线程安全:ConcurrentHashMap 保证并发读写安全,但 Connection 本身不是线程安全的,禁止在多个线程间共享同一 Connection 实例;
-
事务隔离:若涉及事务,请确保复用连接时事务边界清晰,避免跨查询污染;
-
连接泄漏风险:务必在应用退出或连接长时间空闲时主动调用 connectionCache.values().forEach(Connection::close) 清理,或集成 HikariCP / Druid 等连接池自动管理。
? 进阶建议:
对于更复杂的多租户或多环境场景,可将 DataSource 本身缓存(而非 Connection),利用连接池(如 HikariCP)的内置连接复用能力,再结合 ThreadLocal 实现单次请求内连接透传,兼顾性能与安全性。
通过上述改造,你不仅能实现 "current" 连接的零冗余复用,还能为未来扩展其他连接策略(如读写分离、故障转移)打下坚实基础。