Java工程实践中数据库连接池的配置与优化

1. 背景：为什么连接池是“刚需”

在单体或微服务系统中，数据库访问是绕不过去的瓶颈。每一次 DriverManager.getConnection() 都会经历：

1. TCP 三次握手
2. MySQL 认证（用户名/密码、权限校验）
3. 建立会话、分配线程、初始化会话变量

在高并发场景下，频繁创建/销毁连接会让 CPU 空转在 syscall 与上下文切换，吞吐量急剧下降。连接池通过 池化复用 解决了这一问题。

2. 选型：HikariCP 凭什么成为 Spring Boot 2.x 之后的默认

结论：追求极致性能选 HikariCP；需要企业级监控选 Druid；老项目迁移可考虑 c3p0。

3. 核心参数解剖

3.1 HikariCP 必配参数

3.2 MySQL 服务端参数联动

-- 查看当前 wait_timeout
SHOW VARIABLES LIKE 'wait_timeout';
-- 建议设置
SET GLOBAL wait_timeout = 1800; -- 30min，与 maxLifetime 对齐

4. 从 0 到 1 落地：多环境配置示例

4.1 Spring Boot 3.x + HikariCP 的 yml 配置

spring:
  datasource:
    url: jdbc:mysql://127.0.0.1:3306/demo?useSSL=false&serverTimezone=UTC
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver
    hikari:
      # 连接池核心参数
      maximum-pool-size: 20
      minimum-idle: 0
      connection-timeout: 3000
      idle-timeout: 60000
      max-lifetime: 1800000
      leak-detection-threshold: 10000
      # 连接测试
      validation-timeout: 1000
      connection-test-query: SELECT 1

4.2 多数据源场景：读写分离

@Configuration
public class DataSourceConfig {
    @Bean
    @Primary
    @ConfigurationProperties(prefix = "spring.datasource.master")
    public DataSource masterDataSource() {
        return DataSourceBuilder.create()
                .type(HikariDataSource.class)
                .build();
    }

    @Bean
    @ConfigurationProperties(prefix = "spring.datasource.slave")
    public DataSource slaveDataSource() {
        return DataSourceBuilder.create()
                .type(HikariDataSource.class)
                .build();
    }

    @Bean
    public DataSource routingDataSource() {
        Map<Object, Object> target = new HashMap<>();
        target.put("master", masterDataSource());
        target.put("slave", slaveDataSource());
        RoutingDataSource routing = new RoutingDataSource();
        routing.setTargetDataSources(target);
        routing.setDefaultTargetDataSource(masterDataSource());
        return routing;
    }
}

4.3 监控指标接入 Micrometer

@Bean
public MeterRegistryCustomizer<MeterRegistry> hikariMetrics() {
    return registry -> registry.config()
            .namingConvention(NamingConvention.dot);
}

@PostConstruct
public void bindHikariMetrics() {
    HikariDataSource ds = (HikariDataSource) routingDataSource();
    new HikariMetricsBinder().bindTo(meterRegistry, ds, "master-db");
}

Prometheus 抓取后，Grafana 展示：

• hikaricp_connections_active
• hikaricp_connections_timeout_total

5. 性能调优实战

5.1 压测脚本

使用 JMH 模拟 200 并发线程，每个线程执行 1000 次查询：

@BenchmarkMode(Mode.Throughput)
@Threads(200)
@State(Scope.Benchmark)
public class PoolBenchmark {
    private HikariDataSource ds;

    @Setup
    public void setup() {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl("jdbc:mysql://localhost:3306/demo");
        config.setUsername("root");
        config.setPassword("123456");
        config.setMaximumPoolSize(20);
        ds = new HikariDataSource(config);
    }

    @Benchmark
    public void query() throws SQLException {
        try (Connection conn = ds.getConnection();
             PreparedStatement ps = conn.prepareStatement("SELECT 1")) {
            ps.executeQuery();
        }
    }
}

5.2 调参前后对比

• 初始：QPS 3.2k，99.9th RT 120 ms
• 将 maximumPoolSize 从 10 调到 20：QPS 6.1k，99.9th RT 65 ms
• 继续调到 40：QPS 6.3k，99.9th RT 63 ms（收益递减，DB CPU 占用 90%）

经验公式：
最佳连接数 ≈ (CPU 核心数 * 2) + 有效磁盘数，可通过 SHOW PROCESSLIST 观察 State='Sending data' 的线程数微调。

5.3 慢 SQL 与连接池的耦合优化

连接池再快也救不了慢 SQL。通过 druid wall filter 或 MySQL slow log 拿到慢 SQL：

-- 开启慢查询
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 0.1;

优化后，连接池等待队列从 200 降到 10，RT 从 120 ms 降到 20 ms。

6. 常见“坑”与排查清单

6.1 Too many connections

• 现象：应用启动报 MySQLNonTransientConnectionException
• 根因：
  1. maximumPoolSize 过高
  2. Kubernetes 滚动发布，旧 Pod 未优雅下线
• 解决：
  1. 调小 maximumPoolSize
  2. 配置 spring.lifecycle.timeout-per-shutdown-phase=30s

6.2 连接泄露

• 现象：日志出现 Connection leak detection
• 根因：
  1. 忘记 close()
  2. 使用 Spring @Transactional 时，手动 conn.setAutoCommit(true) 导致事务管理器未释放
• 排查：
  1. 打开 leakDetectionThreshold
  2. 在 IDE 中搜索 DataSourceUtils.releaseConnection 调用栈

6.3 连接被防火墙强制关闭

• 现象：偶发 Communications link failure
• 根因：AWS/阿里云 SLB 空闲 60 s 后断开
• 解决：
  1. maxLifetime 设 55 s
  2. 开启心跳：

  hikari:
    validation-query: SELECT 1
    validation-timeout: 3000
  

7. 未来展望：R2DBC 与 Vert.x

虽然 HikariCP 仍是同步 JDBC 的王者，但响应式编程兴起后，R2DBC 提供了非阻塞连接池。其核心差异：

• 连接不再绑定到线程，而是 Publisher<Connection>
• 背压控制：数据库慢时，应用自动限流

示例：

ConnectionFactory factory = ConnectionFactories.get(
        "r2dbc:mysql://root:123456@localhost:3306/demo");
ConnectionPoolConfiguration config = ConnectionPoolConfiguration.builder(factory)
        .maxSize(20)
        .build();
ConnectionPool pool = new ConnectionPool(config);

8. 总结

1. 先压测，再调参：没有监控的优化都是“玄学”。
2. 连接池 + SQL 优化：缺一不可，慢 SQL 会放大池化收益。
3. 云原生时代：关注滚动发布、弹性扩缩容对连接数的影响。