1. 连接池基础概念
1.1 连接池的定义与作用
连接池（Connection Pool）是一种在应用启动时预先创建并维护一定数量数据库连接的资源管理技术。其核心思想是复用连接，避免每次请求都经历“建立连接 → 执行SQL → 关闭连接”的高成本过程。
关键认知： 数据库连接的建立是重量级操作——TCP三次握手、数据库认证、会话上下文初始化，单次耗时通常在 10~100ms 量级。连接池通过复用机制，将这部分开销从每次请求中剥离。
连接池的主要作用可归纳为以下四点：
| 作用维度 | 具体说明 | 性能影响 |
|---|---|---|
| 资源复用 | 已建立的连接不销毁，重复用于多个请求 | 消除连接建立/销毁的CPU与网络开销 |
| 流量控制 | 通过最大连接数限制并发请求量 | 防止数据库被突发流量打垮 |
| 快速响应 | 请求到来时直接从池中获取可用连接 | 减少请求排队等待时间 |
| 连接健康管理 | 定期检测、剔除失效连接，自动补充 | 避免因连接泄漏或断连导致的故障 |
1.2 连接池核心参数详解
连接池的配置直接影响系统吞吐量与稳定性。以下四个参数是调优的基本杠杆：
| 参数名称 | 定义 | 典型值范围 | 设置过小的影响 | 设置过大的影响 |
|---|---|---|---|---|
最小连接数minIdle |
池中保持的最少空闲连接数 | 2 ~ 10 | 突发流量时需新建连接，响应变慢 | 空闲连接占用数据库资源 |
最大连接数maxActive |
池中允许的最大活跃连接数 | 10 ~ 200 | 请求被阻塞或拒绝 | 数据库连接数超限，引发性能雪崩 |
超时时间connectionTimeout |
从池中获取连接的等待超时 | 1000 ~ 5000 ms | 正常请求易被误判为超时 | 故障时请求堆积，拖垮应用 |
最大等待时间maxWait |
连接被占用时，请求的最大排队时间 | 500 ~ 3000 ms | 短时峰值下频繁抛出异常 | 用户感知延迟增加 |
实践建议： 最小连接数应设置为日常并发峰值的 20%~30%，最大连接数不超过数据库实例允许的最大连接数的 70%。超时时间与最大等待时间建议从 2000ms 开始，通过压测逐步下调。
1.3 连接池工作流程
下图展示了连接池从初始化到请求处理的核心流程：
1.4 参数配置的权衡原则
连接池参数并非越大越好，需要遵循以下三条核心原则：
- 匹配数据库容量： 最大连接数 ≤ 数据库实例 max_connections × 0.7，预留 30% 给管理工具、后台任务。
- 匹配应用并发模型： 同步阻塞模型（如 Tomcat + JDBC）需要更多连接；异步非阻塞模型（如 Netty + R2DBC）连接数可大幅减少。
- 匹配响应时间要求： 超时时间应 ≤ 业务容忍的 P99 延迟，避免连接等待成为瓶颈。
常见误区： 很多团队将最大连接数设置得极大（如 500+），认为这样可以提升吞吐量。实际上，当连接数超过数据库 CPU 核心数的 2~3 倍时，上下文切换开销会急剧上升，吞吐量反而下降。连接池不是越大越好，而是够用且留有余量。
1.5 连接池状态模型
连接池内部维护三种连接状态，理解它们有助于精准调参：
| 状态 | 定义 | 对性能的影响 | 监控指标 |
|---|---|---|---|
活跃连接active |
正在被线程使用的连接 | 活跃数接近 maxActive 时，新请求需等待 | activeCount |
空闲连接idle |
已建立但未被使用的连接 | 空闲数低于 minIdle 时，池会补充新连接 | idleCount |
等待线程pending |
因无可用连接而阻塞的请求线程 | 等待数持续 > 0 说明连接池容量不足 | pendingCount |
通过监控这三个指标，可以快速判断连接池的水位健康度：
- activeCount 长期接近 maxActive → 考虑增大最大连接数或优化SQL执行时间。
- idleCount 长期远高于 minIdle → 连接资源浪费，可适当降低 minIdle。
- pendingCount 频繁 > 0 → 连接池已满且请求超时风险高，需紧急扩容或限流。