JDBC连接池

JDBC与连接池组件

在高性能 Java 应用中，数据库连接池（Connection Pool）是优化系统响应速度、保障数据库稳定性的核心组件。

• 示例代码

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class JdbcQueryDemo {
  private static final String URL = "jdbc:mysql://127.0.0.1:3306/demo"
      + "?useSSL=false&serverTimezone=UTC&characterEncoding=utf8";
  private static final String USER = "demo_user";
  private static final String PASS = "demo_pass";

  public static void main(String[] args) {
    String sql = "SELECT id, name, created_at FROM users WHERE status = ? LIMIT ?";

    try (Connection conn = DriverManager.getConnection(URL, USER, PASS);
       PreparedStatement ps = conn.prepareStatement(sql)) {

      ps.setString(1, "ACTIVE");
      ps.setInt(2, 10);

      try (ResultSet rs = ps.executeQuery()) {
        while (rs.next()) {
          long id = rs.getLong("id");
          String name = rs.getString("name");
          String createdAt = rs.getString("created_at");
          System.out.printf("id=%d, name=%s, created_at=%s%n", id, name, createdAt);
        }
      }
    } catch (SQLException e) {
      e.printStackTrace();
    }
  }
}

• 关键组件与调用流程

为什么要用池化技术？

传统的 JDBC 操作（DriverManager.getConnection()）是重量级的。每次请求都要经历：

1. TCP 三次握手：网络层建连。
2. 身份验证：数据库层校验用户名密码。
3. 分配资源：数据库为该会话分配内存和进程。
4. SQL 执行与结果传输。
5. 四次挥手：断开连接。

连接池的价值：

• 资源复用：连接在池中常驻，消除建连和销毁的开销。
• 流量削峰：通过 maxActive 限制并发数，保护数据库不被瞬时请求击垮。
• 连接健康监测：自动检测死连接并进行剔除或重连。

主流连接池对比：HikariCP vs Druid

目前生产环境下，基本只推荐这两款产品：

HikariCP (极致的快)

• 地位：Spring Boot 2.x 默认内置。
• 默认值：最大连接数 10，最小空闲 10。
• 黑科技：
  • 字节码精简：优化了代理对象的生成。
  • FastList：自定义集合，替代 ArrayList，减少数组边界检查。
  • 无锁编程：大量使用 ThreadLocal 缓存连接，减少锁竞争。

Druid (全能监控)

• 地位：国产之光，阿里开源。
• 默认值：最大连接数 8，最小空闲 0。
• 核心优势：
  • 监控视图：内置 StatViewServlet，可直观查看 SQL 执行耗时、慢查询、并发峰值。
  • 防 SQL 注入：内置 WallFilter 防火墙，从连接池层面对 SQL 风险进行过滤。

关键参数与性能计算

连接池配置不是越大越好，而是要寻找**吞吐量（QPS）与响应时间（RT）**的平衡点。

核心公式

理论单机 QPS 预估：

QPS ≈ PoolSize / Avg_RT

注：Avg_RT 包含网络往返延迟。

参数调优准则

• maximumPoolSize (maxActive)：
  • 数据库侧建议：通常建议为 CPU 核心数 * 2 ~ CPU 核心数 * 4。
  • 业务侧建议：如果 SQL 耗时极短（<10ms），30-50 个连接足以支撑几千并发；如果 SQL 较慢，应优先优化 SQL 而非盲目扩大连接池。
• minimumIdle：建议设置为与最大值相同（HikariCP 的默认做法），防止在流量突增时因为创建新连接产生的性能抖动。
• connectionTimeout：建议 3-5 秒。若超过此时间拿不到连接，说明系统已达到瓶颈，应及时报错触发熔断，而不是让用户无限等待。

生产环境稳健配置模板 (YAML)

基于 Spring Boot + HikariCP 的推荐配置：

spring:
  datasource:
    hikari:
      # 1. 基础大小配置
      maximum-pool-size: 50      # 根据压测调整，通常 20-50 足够
      minimum-idle: 50           # 保持池子预热

      # 2. 超时控制
      connection-timeout: 3000   # 3秒拿不到连接就报错，防止拖死前端
      idle-timeout: 600000       # 10分钟清理一次多余连接
      max-lifetime: 1800000      # 30分钟强制换新，防止连接老化被数据库强制断开

      # 3. 性能优化 (MySQL 专用)
      data-source-properties:
        cachePrepStmts: true              # 开启预编译 SQL 缓存
        prepStmtCacheSize: 250            # 缓存的 SQL 数量
        prepStmtCacheSqlLimit: 2048       # 缓存的单条 SQL 最大长度
        useServerPrepStmts: true          # 使用服务器端预编译

避坑指南

1. 连接泄露：最致命。确保使用 try-with-resources 或在 finally 块中关闭 Connection/Statement。
2. 网络分区：如果应用和数据库中间有防火墙，防火墙可能会杀掉长时间不活跃的连接。务必设置 keepalive 或确保 max-lifetime 小于防火墙超时时间。
3. 大事务：一个长达 10 秒的大事务会占用连接不释放，这会让连接池的 QPS 预估公式失效。

连接池大小与 QPS 预估

预估连接池能支撑的 QPS (Queries Per Second) 并不是一个简单的公式就能解决的，它取决于木桶效应中最短的那根木板（通常是数据库磁盘 I/O 或 CPU）。

不过，我们可以通过以下逻辑进行科学的“掐指一算”：

怎么预估连接池大小和能支撑的 QPS？

核心计算公式

在理想状态下，QPS 与连接数和执行耗时的关系如下：

• 例子： 如果你的连接池大小设置为 10，每条 SQL 执行平均需要 10ms（即 0.01s）。
• 理论 QPS： QPS = 10 / 0.01 = 1000。

注意： 这只是单个应用的理论值。如果你的 SQL 变慢（比如 100ms），QPS 会瞬间掉到 100。

如何确定最佳连接数 (PoolSize)？

连接数并不是越多越好。过多的连接会导致数据库频繁进行上下文切换，反而降低性能。

PostgreSQL 提供了一个著名的经验公式（同样适用于 MySQL）：

PoolSize = CPU 核心数 * 2 + 有效磁盘数

“有效磁盘数”指的是数据库能并行处理 I/O 的独立存储通道数量

通俗建议：

• IO 密集型（常规业务）： 建议设置为 CPU 核心数 * 2 到 CPU 核心数 * 4。
• 计算密集型： 建议设置为 CPU 核心数 + 1。

影响预估的关键变量

要得到准确的 QPS 预估，你必须考虑以下三个现实因素：

A. 数据库瓶颈（DB Limit）

连接池只是“管道”，水源在于数据库。如果数据库 CPU 达到 90%，增加连接池大小只会让响应更慢。

B. 网络延迟（Network Latency）

SQL 执行耗时 = 网络往返时间 + 数据库处理时间 + 结果集传输时间。 如果应用和数据库不在同一个机房，网络延迟会成为 QPS 的天花板。

C. 并发用户数与连接池等待

在高并发下，如果连接池满了，新的请求会进入 Waiting 状态。如果等待时间超过了你设置的 connectionTimeout（默认通常 30s），系统就会开始抛出异常。

压力测试：最真实的预估方法

公式只能定性，压测才能定量。推荐步骤：

1. 基准测试： 将连接池设为较小值（如 10），观察 CPU 和 QPS 曲线。
2. 寻找拐点： 逐渐增加连接数（20, 40, 60…），观察 QPS 是否线性增长。
3. 确定上限： 当 QPS 不再增长，或者响应时间（Response Time）开始剧烈抖动时，当前的连接数就是该环境下的最优解。

总结建议

如果你是一个中型项目（4 核 8G 数据库）：

• 初始设置： 20-50 个连接。
• QPS 预期： 如果 SQL 优化得当（均在 5ms 内），单机支撑 3000-5000 QPS 是很轻松的。