java应用应使用hikaricp等成熟连接池复用数据库连接，避免手动创建销毁；需合理配置minimumidle、maximumpoolsize等参数，并通过try-with-resources确保连接归还，防止泄漏。
Java 应用通过连接池复用数据库连接，核心是避免频繁创建和销毁 Connection 对象——这类对象初始化成本高（含网络握手、认证、事务上下文准备等），直接 new 或 DriverManager.getConnection() 每次都走完整链路，性能损耗明显。连接池把连接“管起来”，用完不销毁，而是归还给池，下次直接取，从而大幅降低对象创建与资源分配开销。
选对连接池实现，避免轻量级陷阱
别用 BasicDataSource（DBCP1）或原生 DriverManager 手动管理；优先选成熟、生产就绪的池：
- HikariCP：字节码精简、无反射、CPU 缓存友好，启动快、延迟低，当前事实标准
- Druid：功能全（监控、SQL 防火墙、加密）、阿里系常用，但堆内存占用略高
- Tomcat JDBC Pool：Spring Boot 早期默认，稳定但活跃度已不如前两者
它们内部都用阻塞队列 + 线程安全容器管理连接，支持预热、空闲检测、最大最小连接数控制，不是简单 List 存 Connection。
配置关键参数，让复用真正生效
光引入依赖不够，不合理配置会让连接池“形同虚设”：
- minimumIdle：设为 5~10（非 0），确保池中常驻可用连接，避免突发请求时才新建
- maximumPoolSize：根据 DB 最大连接数和应用并发量设（如 DB 允许 200 连接，应用有 4 实例 → 单实例设 40~50），超限会排队或抛异常
- connectionTimeout：设 30s 左右，防止线程无限等待空闲连接
- idleTimeout / maxLifetime：让长期空闲或老化连接自动回收，避免 DB 端因超时断连导致应用报错
Spring Boot 中可通过 spring.datasource.hikari.* 直接配置，无需写硬编码。
正确使用连接，不破坏复用链条
拿到连接后必须归还，否则连接泄漏，池很快耗尽：
- 用 try-with-resources（
Connection、Statement、ResultSet都需自动关闭） - 不要在 service 层 long-lived 地持有 Connection，它只应在 DAO/Repository 方法内短周期使用
- 避免在 finally 块里手动 close —— HikariCP 的 close() 实际是归还到池，不是物理关闭；但若误调用了
con.close()且未用池包装类，可能真关掉
示例正确写法：
try (Connection con = dataSource.getConnection();PreparedStatement ps = con.prepareStatement("SELECT * FROM user WHERE id = ?")) {
ps.setLong(1, userId);
try (ResultSet rs = ps.executeQuery()) {
// 处理结果
}
}
验证是否真的复用了连接
别只看日志或文档，实测确认：
- 开启 HikariCP 的
debug日志（com.zaxxer.hikari设为 DEBUG），观察 “HikariPool-1 - Before cleanup”、“HikariPool-1 - After cleanup” 及获取/归还记录 - 在 SQL 中加注释标识来源，如
/* user-service-findById */ SELECT * FROM user...，再查 DB 的 processlist（MySQL）或 pg_stat_activity（PostgreSQL），看连接的 client_hostname 和 application_name 是否稳定，而非每次变 - 压测时监控池指标：activeConnections、idleConnections、threadsAwaitingConnection，若 threadsAwaitingConnection 长期 > 0，说明池太小或连接未释放
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
