连接池是预创建并复用connection对象的机制，避免每次sql都新建tcp连接；实测建连耗时80–150ms，远超sql执行本身；需合理设maximum-pool-size与minimum-idle，正确归还连接防泄漏。
连接池不是“池子”，而是一套连接复用机制
连接池本质是程序启动时预先创建一批 Connection 对象，放进内存里统一管理，并在后续数据库操作中反复使用它们——而不是每次 executeQuery() 都新建一个物理 TCP 连接。它不改变 JDBC 协议，但彻底绕开了“三次握手→认证→SQL→四次挥手”这套重操作流程。
为什么不用连接池，一条 SQL 会多花 200ms+
实测典型场景下：建立 MySQL 连接平均耗时 80–150ms（含网络延迟、SSL协商、权限校验），关闭连接也有 20–40ms。而真正执行 SELECT COUNT(*) FROM user 可能只要 2ms。也就是说，95% 的时间花在“准备干活”上，不是“干活”本身。
- 高并发时大量
TIME_WAIT状态堆积，Linux 默认 60 秒才能回收，容易占满本地端口 - MySQL 服务端为每个连接分配线程/内存，连接数冲到 200+ 就可能触发
Too many connections - 频繁 GC：每次 new Connection 产生大量临时对象，JVM 压力陡增
HikariCP 的 minimum-idle 和 maximum-pool-size 怎么设才不翻车
盲目调大 maximum-pool-size 是线上最常见错误——它不会提升性能，只会把数据库压垮。真实经验值来自硬件与负载特征：
-
maximum-pool-size推荐值 =(CPU核心数 × 2) + 有效磁盘数（例如 4 核 SSD 服务器 →9；若业务含大量 IO 等待，可放宽至15–20） -
minimum-idle不建议设为 0：冷启动后首个请求仍要建连，应设为maximum-pool-size的 30%～50%，比如最大 20，最小就设8 - 必须配
connection-timeout（建议30000），否则连接池取不到连接时会无限阻塞线程
归还连接不是 conn.close()，而是“放回池里”
这是开发者踩坑率最高的点：调用 conn.close() 在连接池环境下 ≠ 关闭物理连接，而是通知池子“我用完了，请回收复用”。但如果忘了这一步，或在异常分支里漏写，就会导致连接泄漏——池子里的可用连接越来越少，最终所有请求卡在 getConnection() 上等待。
- 务必确保每个
try都配对finally { if (conn != null) conn.close(); } - 更安全的做法是用 try-with-resources（JDK 7+），
Connection实现了AutoCloseable，自动触发归还逻辑 - 启用 HikariCP 的
leak-detection-threshold（如设为60000），超时未归还会打日志报警
