JDBC本身不提供连接池功能，Connection Pool由第三方库实现，通过代理Connection对象管理“创建—使用—归还”生命周期，连接不真正关闭而是复用；初始化预建连接、借用时分配代理、使用中拦截方法、归还时重置状态并放回空闲队列、销毁时关闭物理资源。
JDBC 本身不提供连接池功能，Connection Pool 是在 JDBC 基础上由第三方库（如 HikariCP、Druid、C3P0）实现的资源管理机制。它通过封装和代理 java.sql.Connection，将“创建—使用—归还”转变为受控的生命周期管理，而非传统方式中的“每次 new、用完 close”。核心在于：连接不再被真正关闭，而是回收复用。
连接池如何接管 Connection 生命周期
连接池在初始化时按配置预建一批物理连接，并维护空闲队列与活跃队列。当调用 dataSource.getConnection() 时，池返回一个代理对象（如 HikariProxyConnection），该对象持有真实连接引用，同时绑定借用上下文（如线程栈快照用于泄漏检测）。使用结束后调用 close()，实际执行的是归还逻辑——重置状态、校验有效性、放回空闲队列，而非关闭底层 socket。
关键生命周期阶段与对应操作
-
初始化（Init）：应用启动时，连接池根据
minimumIdle创建初始连接，尝试执行connectionTestQuery验证连通性；失败则重试或抛异常 -
借用（Borrow）：从空闲队列取连接；若空闲不足且未达
maximumPoolSize，则新建；否则阻塞等待connectionTimeout后报错 -
使用（Use）：代理连接拦截
close()、commit()、rollback()等方法，确保事务边界清晰；自动启用setAutoCommit(false)配合手动事务控制 -
归还（Return）：调用
close()触发回收流程——清除 ThreadLocal 上下文、重置隔离级别与只读状态、执行validationQuery（可选）、加入空闲队列；若连接超时（maxLifetime）或失效，则直接丢弃并重建 -
销毁（Destroy）：调用
dataSource.close()时，逐个关闭所有物理连接，释放线程池与定时任务等内部资源
防止生命周期失控的实用措施
连接泄漏和状态污染是常见故障源，需主动防控：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 始终用
try-with-resources获取连接，确保close()在异常路径下也执行 - 启用泄漏检测：
leakDetectionThreshold=60000（毫秒），超时未归还会打印堆栈定位问题代码 - 设置
maxLifetime=1800000（30 分钟）强制淘汰长连接，避免数据库端因 wait_timeout 断连 - 禁用连接自动提交后，务必显式调用
commit()或rollback()，否则连接归还时可能仍处于事务中，影响复用 - 避免在连接上绑定业务对象或修改其内部属性（如
setCatalog()），除非明确知道池支持连接状态重置
监控连接池状态辅助生命周期判断
通过 JMX 或池自带 API（如 Hikari 的 HikariDataSource.getHikariPoolMXBean()）实时查看：activeConnections、idleConnections、threadsAwaitingConnection、totalConnections。若长期 active == maximumPoolSize 且 awaiting > 0，说明连接未及时归还或存在慢 SQL 占用；若 idle 持续为 0 但 active 波动剧烈，可能是连接频繁创建销毁——说明池未生效或配置过小。
立即学习“Java免费学习笔记（深入）”；
