连接池是为解决直连模式下TCP握手、SSL协商、认证等高开销问题而生的复用机制，核心是预建连接、获取即用、用完归还而非关闭，本质是以空间换时间。
连接池不是“配完就完事”的组件，它是 Java 应用数据库性能的底层支柱。复习时别堆概念，要抓主线：为什么需要它 → 它怎么工作 → 关键参数怎么影响行为 → 常见坑在哪。
理解连接池存在的根本原因
直连模式每次 getConnection() 都要走 TCP 握手、SSL 协商、身份认证、权限校验，耗时几十到几百毫秒。高并发下频繁创建/销毁连接，不仅拖慢应用，还会压垮数据库（比如 MySQL 默认最大连接数 151）。连接池的本质是“空间换时间”——提前建好一批连接放着，谁要用谁取，用完不关只还。
- 对比记忆：把连接池想象成地铁闸机口的“单程票回收箱”。你刷一次进站（获取连接），出站时把卡塞进箱（归还），工作人员晚上统一清点补票（连接复用），而不是每趟车都重印一张新卡（新建连接）
- 重点区分：
Connection.close()在连接池环境下不是真的关闭，而是触发归还逻辑；只有池本身销毁时，才会批量关闭物理连接
掌握主流连接池的核心差异与选型依据
不用死记所有池，盯住三个主流：HikariCP、Druid、DBCP。它们都实现 javax.sql.DataSource 接口，所以上层代码可切换，但内部机制和适用场景不同。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
HikariCP：性能优先，代码极简，无额外依赖。适合 Web 服务、微服务等对延迟敏感的场景。它的“fast path”设计让获取连接几乎无锁，
maximumPoolSize和minimumIdle是必须调优的两个参数 -
Druid：功能最全，带 SQL 监控、防火墙、统计面板。适合金融、政企等需要审计和安全控制的系统。注意它默认开启连接泄露检测（
removeAbandonedOnBorrow=true），上线前需确认是否符合业务超时预期 - DBCP（尤其是 DBCP2）：Apache 老牌池，稳定但性能一般。适合已有 Tomcat 环境或对第三方依赖要求严格的遗留项目。配置项多，容易误配，建议用 Spring Boot 自动配置而非手动 new
吃透五个关键配置参数的实际含义
参数不是填数字，每个值背后都有资源权衡。拿 HikariCP 为例：
立即学习“Java免费学习笔记（深入）”；
-
maximumPoolSize：不是越大越好。设太高会导致数据库线程数爆满、内存溢出、锁竞争加剧。建议从 20 开始压测，逐步调到响应时间和 DB CPU 双达标为止 -
minimumIdle：池中常驻的最小空闲连接数。设太低，突发流量来临时要临时创建连接，失去池的意义；设太高，空闲连接占着 DB 连接数却不干活，浪费资源 -
connectionTimeout：应用等待连接的最长时间。设太短（如 100ms），流量高峰时大量请求直接失败；设太长（如 30s），用户白屏等待，体验差。通常设为 3~10 秒较合理 -
idleTimeout：空闲连接在池中存活多久后被回收。避免长期空闲连接被数据库主动断开（MySQL wait_timeout 默认 8 小时），导致下次取出时报 “Connection closed” -
maxLifetime：连接从创建起最长存活时间。强制刷新连接，防止因数据库重启、网络抖动、证书过期等问题导致的隐性失效
识别并规避三类高频问题
面试和线上故障里，80% 的连接池问题集中在这几类：
-
连接泄漏：没调
close()或 try-with-resources 漏写。现象是空闲连接数持续下降，活跃连接数顶到maximumPoolSize，后续请求全部超时。解决靠监控（Druid 控制台 / HikariCP 的 metrics）+ 代码扫描（SonarQube 规则） -
连接失效：数据库重启、网络闪断后，池中部分连接已断开但未被及时剔除。现象是偶发 “Connection reset” 或 “Communications link failure”。解决靠启用
connectionTestQuery（MySQL 用SELECT 1）或健康检查 -
参数错配：比如把
maxWait（旧版 DBCP 参数）误用在 HikariCP 上，或把initialSize设得远大于minimumIdle导致启动慢。务必对照官方文档看参数归属版本
