连接池概念与作用
说起连接池，咱们先从一件事聊起。
你写了一个 Web 应用，每次用户请求进来，都要去查数据库。常规做法是什么？打开连接 → 执行 SQL → 关闭连接。对吧？
我以前接手过一个后台系统，日均请求量不到一万，但 DBA 天天报警说数据库连接数超标。我上去一看，代码里每次查询都 new 一个 Connection，用完就 close。表面上看没问题，但你知道每个连接的背后是什么吗？TCP 三次握手、数据库认证、会话上下文创建……这一套下来，几十毫秒就没了。请求量一上去，数据库直接被连接请求冲垮。
嗯，这就是没有连接池的典型症状。
连接池到底是什么
说白了，连接池就是一个「复用连接」的容器。
你在系统启动时预先创建一批数据库连接，放进一个池子里。后续请求来了，直接从池子里拿一条，用完再还回去。这样就不需要每次都经历完整的建连过程。
一句话总结：连接池的核心思路，就是把「创建连接」这个昂贵操作提前做、集中做，然后反复利用。
我记得第一次看 HikariCP 源码时，发现它连连接状态的检测都做得极轻量。为什么？因为连接池本身就不能成为瓶颈。你想想看，如果拿个连接都要排队等锁，那跟每次新建连接有什么区别？
为什么需要连接池
这个问题我问过不少人，答案五花八门。但核心原因其实就三条。
| 对比项 | 无连接池 | 有连接池 |
|---|---|---|
| 连接建立耗时 | 每次 20~50ms（TCP+认证） | 从池中获取 ≈ 0~1ms |
| 数据库连接数 | 随请求并发直线上升 | 受池大小限制，可控 |
| 系统资源开销 | 大量 TIME_WAIT 套接字 | 连接复用，开销极低 |
| 故障恢复 | 手动重连或抛异常 | 自动检测 + 重建 |
我在项目里见过最夸张的情况：一个没配连接池的服务，高峰时建连耗时占了总响应时间的 40%。你算算，100ms 的接口，40ms 花在握手和认证上，这笔账划不来。
我曾经犯过一个错：觉得连接池配大一点总没错，直接把 Tomcat JDBC 的 maxActive 设成 200。结果数据库连接数爆了，连管理工具都登不上去。教训就是：连接池不是越大越好，得跟数据库的 max_connections 配合着来。
连接池的核心价值
这里我归纳四点，也是我这些年调优时反复验证过的。
- 降低延迟：复用已建连接，省去 TCP 握手 + 认证的往返时间。高并发场景下效果特别明显。
- 控制资源：池大小就是硬上限，防止数据库被突发流量冲垮。你想想，如果没有这个限制，一个 for 循环就能把数据库打挂。
- 连接治理：自动检测失效连接、空闲回收、泄漏追溯。这些功能让运维轻松不少。
- 性能稳定：预热后的连接池，响应时间曲线非常平缓。不像无池模式，冷启动和高峰期落差巨大。
我最近在调一个金融系统的接口，它的核心服务用了 Druid 连接池。一开始用的是默认配置，压测到 500 并发就报「connection is not available」。后来我把 poolPreparedStatements 打开，maxWait 设成 3000ms，连接数从 50 降到 20，反而扛住了 2000 并发。你说奇不奇怪？但仔细一想就明白了：连接复用率上去了，上下文切换少了，自然就稳了。
一个小技巧：如果业务有明显的波峰波谷，可以用动态连接池。或者至少把 minimumIdle 设成比高峰期略低的值，避免池子频繁缩放过快。
你从图上可以明显看出来：左边每次请求都要经历「建连 → 使用 → 销毁」的完整周期。右边只需要一次建连，后面全是复用。这就是连接池的本质——用空间换时间。
小结
连接池不是什么新概念，但很多工程师其实没真正吃透。我见过不少项目，连接池配了，但配得一塌糊涂：要么太小导致请求排队超时，要么太大把数据库撑爆。说到底，还是要理解它背后的设计思想——资源复用、流量控制、故障隔离。
这一章咱们把概念打扎实了，后面再聊参数调优时，你就能明白每个配置项到底在控制什么。