1. 连接池概述：为什么需要连接池，连接池工作原理

做 Java 开发的朋友，十有八九都跟数据库打过交道。我记得刚入行那会儿，写了个简单的用户登录模块，每次请求都 new 一个 Connection，用完了就 close。上线第一天，系统直接挂了——数据库连不上了。

后来一查，原来是频繁创建和销毁连接把数据库搞垮了。从那天起，我就再也不敢直连数据库了。说白了，连接池就是解决这个问题的。

为什么需要连接池

你想想看，建立一次数据库连接，背后发生了什么？TCP 三次握手、数据库认证、会话上下文创建……这些开销少说几十毫秒，重的时候几百毫秒。如果每次业务请求都经历一次，系统的吞吐量直接被拉垮。

我在一个高并发项目中做过对比：同样 1000 次查询，用直连平均耗时 45 秒，改用连接池后降到 2.1 秒。差距就在这里。

连接池带来的好处，我归纳成三点：

• 复用连接——避免频繁创建和销毁，降低系统开销。
• 控制并发——限制最大连接数，防止数据库被打爆。
• 快速响应——从池中直接拿空闲连接，几乎零等待。

嗯，还有一个容易被忽略的点——统一管理连接生命周期。比如连接空闲太久会被数据库主动断开，连接池可以自动检测并重建，避免业务拿到“半死不活”的连接。我在项目中遇到过好几次“连接未关闭导致连接泄漏”的故障，后来全靠连接池的泄漏检测机制兜底。

连接池工作原理

连接池的设计思路其实很朴素：提前创建一批连接，放到一个“池子”里存着。业务需要时从池子取，用完再还回去。核心流程分三步：初始化、获取、归还。

初始化阶段

应用启动时，连接池根据配置创建一批“初始连接”。
比如 HikariCP 的 minimumIdle 设置为 10，它就预先建好 10 条连接放着。这时并没有业务请求，连接都处于“空闲”状态。

获取连接

当一个线程请求连接时，连接池会从空闲队列里取出一个可用连接，标记为“活跃”，然后返回给调用方。如果池里空闲连接用完了，就看是否还能继续创建新连接（未达到 maximumPoolSize），能则新建；不能则让线程等待，直到有连接归还或超时。

这个过程看起来简单，但里面有不少门道。HikariCP 之所以快，在于它用了 ConcurrentBag 这种无锁数据结构，减少了线程争抢。我当初研究源码时，看到它用 CopyOnWriteArrayList 存储连接，同时用 ThreadLocal 缓存，确实高明。

归还连接

业务执行完 SQL，调用 connection.close()。注意，这个 close() 并不是真的关闭 TCP 连接，而是被连接池代理了——实际触发的操作是“归还到池中，状态变回空闲”。

说一个我踩过的坑：曾经在项目中使用了 try-with-resources，但忘了关闭 Statement 和 ResultSet，导致连接归还后，PreparedStatement 还持有游标资源。后来数据库连接数飙升到上限，业务直接熔断。所以，归还连接时，一定要确保所有子资源都释放干净。

核心参数一览

连接池的调优离不开参数搭配。我整理了几个最关键的参数，放在下面表格里：

参数名	作用	默认值	调优建议
maximumPoolSize	池中最大连接数	10	参考 CPU 核心数 × 2 + 磁盘数
minimumIdle	池中保持的最小空闲连接数	10	与 maximumPoolSize 一致时可减少抖动
connectionTimeout	等待连接的超时时间（毫秒）	30000	高并发建议降低到 5000~10000
idleTimeout	连接允许空闲的最大时间（毫秒）	600000	数据库本身会断连时，设为 120000 左右
maxLifetime	连接的最大寿命（毫秒）	1800000	建议小于数据库的连接超时时间

连接池工作流程示意图

下面这张 SVG 图，展示了一次连接从获取到归还的完整流转。我把它画成了带节点和箭头的流程图，方便你理解。

为什么选择 HikariCP

市场上连接池产品不少，Druid、Tomcat JDBC Pool、C3P0……但 HikariCP 的性能表现一直稳居第一。它的设计哲学是“尽可能轻量”，源码才不到 100 个类。我测过在 200 并发下，HikariCP 获取连接的 p99 延迟只有 2~3 毫秒，而其他池至少 10 毫秒以上。

当然，没有银弹。HikariCP 对参数配置敏感，这也是本课程后面要深入的主题。从下一节开始，我们会逐一拆解每个参数的意义和调优技巧。