1. 连接池概念与作用
什么是连接池
先说一个最直观的场景。你写了个 Web 应用，每次用户请求过来都要查数据库。最直接的做法是：收到请求 → 创建数据库连接 → 执行 SQL → 关闭连接。看起来没毛病。但你想想看，在高并发下，每秒钟几百上千个请求，每条请求都在“创建-销毁”连接，这背后的开销有多大？
连接池，说白了就是一个“预先创建好的连接容器”。应用启动时，我预先建好一批数据库连接，把它们放在一个池子里。谁要用，直接从池子里拿；用完了，不是真的关掉，而是归还给池子。就这么简单。
我习惯把连接池理解成“共享单车停放点”。你不需要每次出门都造一辆新车，到停放点扫码骑走，骑完停回去就行。数据库连接池干的就是这个事。
核心定义：连接池是一组预先初始化、可重复使用的数据库连接集合。它由连接池管理器统一维护连接的生命周期。
为什么需要连接池
没有连接池的时候，系统长什么样？我做过的第一个项目就是吃了这个亏——每次请求都手动创建连接，压测到 200 QPS 直接挂了。为什么？
| 对比项 | 无连接池（每次新建） | 有连接池 |
|---|---|---|
| 网络握手 | TCP 三次握手 + MySQL 认证 | 一次初始化，后续零握手 |
| 资源消耗 | 每个连接占用内存、线程、文件描述符 | 固定数量，可预测 |
| 响应时间 | 每次 10-50ms 连接开销 | 接近 0ms 获取连接 |
| 并发能力 | 受限于系统创建连接的速率 | 池内连接复用，吞吐量稳定 |
你看看这个表格就明白了。创建一次 MySQL 连接，底层要走 TCP 三次握手、MySQL 认证、字符集协商，这些步骤加起来少说 10 毫秒，网络差的时候能到 50 毫秒。对于大部分 OLTP 业务，一个请求可能只执行 2-5 毫秒的 SQL，连接开销占比惊人。
我曾经踩过的坑：有一次生产环境出现大量 Too many connections 错误。排查发现是某同事写的定时任务每次执行都 new 连接，没有 close。连接池不仅能复用，还能强制限制最大连接数，避免数据库被打满。
连接池的工作原理
嗯，这里我们要稍微深入一点。连接池内部其实不复杂，我拆成三步来理解：
- 初始化阶段：池管理器按照配置创建指定数量的连接（比如 minIdle=5）。这些连接都处于“空闲”状态，等待被使用。
- 借用阶段：业务代码调用
getConnection()，管理器从空闲队列里取出一个连接，标记为“已占用”。如果空闲队列为空，且未达到最大连接数，就创建新连接；否则，请求等待（超时机制生效）。 - 归还阶段：业务代码调用
close()（实际是归还），连接被重置回空闲状态，放回队列。如果池中空闲连接数超过 maxIdle，多余的连接会被真正关闭。
我在项目中用的 HikariCP，它的核心就是一个 ConcurrentBag 加 ThreadLocal 缓存。读源码时发现它甚至连 synchronized 都很少用，全是 CAS 和弱引用——这也解释了为什么它这么轻量。
小经验：连接池的“借出”和“归还”操作必须是线程安全的。大部分连接池使用 ReentrantLock 或 CAS 实现，性能瓶颈往往不在数据库本身，而在池的内部锁竞争。如果你的应用 QPS 极高（比如上万），可以考虑使用无锁队列实现的连接池，比如 gRPC 用的 Netty ChannelPool。
连接池核心流程示意
为了让你更直观地看到整个生命周期，我画了一张图：
进一步理解：连接池的几项关键参数
光知道流程还不够。你在配置连接池时，有几个参数几乎决定了系统行为。我列一下最常见的：
| 参数 | 含义 | 我的建议 |
|---|---|---|
minimumIdle |
池中保持的最小空闲连接数 | 不要设 0，否则突发流量必须现创建连接，延迟高 |
maximumPoolSize |
池中最多能有多少条连接（含空闲和占用） | 经验公式：max(CPU核数×2, 10)，数据库能扛住即可 |
connectionTimeout |
从池中获取连接的最大等待时间（毫秒） | 我习惯设 3000ms，太长会导致请求堆积 |
idleTimeout |
连接空闲超过多久会被关闭 | 一般 10 分钟，太短会频繁创建销毁 |
maxLifetime |
连接的最大存活时间 | 建议略小于数据库的 wait_timeout，通常 30 分钟 |
特别提醒： maxLifetime 必须小于数据库服务端的连接超时时间。我曾经在生产环境把 HikariCP 的 maxLifetime 设为 60 分钟，但 MySQL 的 wait_timeout 默认是 8 小时。表面看没问题，但一旦网络中存在防火墙或负载均衡器，它们会在 30 分钟后静默断开空闲连接。结果就是池子里的连接实际上不可用，但应用以为还活着——拿到的连接会报 CommunicationsException。这种“幽灵连接”问题很恶心，排查了很久。
连接池的常见实现
聊了这么多概念，最后说说市面上常见的连接池。我用过多种，这里说点个人体感：
- HikariCP：目前 Java 生态最主流的连接池，字节码级优化。我最近三年都在用，压测 3000 QPS 毫无压力。推荐。
- Druid：阿里开源的连接池，功能最全——自带监控、SQL 防火墙、慢查询日志。适合需要深度运维的团队。我在一个金融项目里用过，监控面板真的很强。
- Tomcat JDBC Pool：Tomcat 原生自带，配置简单。如果你没引入其他连接池，可以先用它，但性能不如 HikariCP。
- C3P0 / DBCP：老牌连接池，现在基本不推荐了。性能差，而且有内存泄漏的风险。
我个人的选择策略：非关键业务用 HikariCP + 默认配置起步；关键业务用 Druid + 开启监控。如果用的不是 Java，比如 Python，那么 SQLAlchemy 连接池、psycopg2.pool 本质原理一样，参数大同小异。
好了，这一章我们打好了地基。记住一句话：连接池的核心就是“复用”二字。理解了为什么复用、怎么复用，后续讲超时和优化时，你才能明白每个参数在什么场景下该调、不该调。