📚 课程目录第4章连接等待与超时

4. 连接等待与超时：maxWait、timeBetweenEvictionRunsMillis、minEvictableIdleTimeMillis 参数详解

在支付订单系统中，数据库连接池的稳定性直接决定了接口的响应时间与系统吞吐量。本章聚焦 Druid 连接池中三个核心参数：maxWait（最大等待时间）、timeBetweenEvictionRunsMillis（驱逐运行间隔）和 minEvictableIdleTimeMillis（最小空闲驱逐时间）。这三个参数共同决定了连接分配时的等待行为、空闲连接的回收频率以及连接存活的生命周期。

4.1 参数功能对比

参数名	默认值	核心作用	支付场景典型值
maxWait	-1（无限等待）	从连接池获取连接时的最大阻塞时间（毫秒）	3000～5000
timeBetweenEvictionRunsMillis	60000（1分钟）	空闲连接检测/驱逐线程的运行间隔（毫秒）	30000～60000
minEvictableIdleTimeMillis	1800000（30分钟）	连接在池中保持空闲而不被驱逐的最小时间（毫秒）	300000～600000

4.2 maxWait：连接获取的“超时熔断”

当并发请求超过连接池最大活跃连接数时，后续线程必须等待其他线程归还连接。maxWait 定义了线程愿意等待的最长时间。若超过该时间仍未获取到连接，Druid 会抛出 CannotGetJdbcConnectionException，避免线程无限阻塞导致系统雪崩。

  支付场景案例： 某支付网关在高峰期出现 200 个并发下单请求，连接池最大活跃数为 50。若 maxWait 设置为 5000ms，则等待超过 5 秒的请求直接失败，返回“系统繁忙”提示，保护后端数据库不被压垮。

// Druid 配置示例：maxWait 设置为 3 秒
spring.datasource.druid.max-wait=3000

// 代码中获取连接的超时行为
try (Connection conn = dataSource.getConnection()) {
    // 执行业务逻辑
} catch (SQLException e) {
    if (e.getMessage().contains("maxWait")) {
        // 记录告警：连接获取超时，当前活跃连接数已达上限
        log.warn("获取数据库连接超时，当前活跃连接数：{}", activeCount);
    }
}

调优建议： 支付订单系统建议将 maxWait 设置在 3000～5000ms。过短（<1000ms）会导致正常业务因瞬时抖动而失败；过长（>10000ms）会加剧线程堆积，拖慢整体响应。

4.3 timeBetweenEvictionRunsMillis：驱逐线程的“心跳”

Druid 会启动一个独立的守护线程，定期扫描池中的空闲连接，判断是否需要物理关闭。该线程的运行间隔由 timeBetweenEvictionRunsMillis 控制。间隔越短，连接回收越及时，但也会增加 CPU 和锁竞争开销。

常见误区： 将 timeBetweenEvictionRunsMillis 设置得极短（如 1000ms）并不会显著提升连接健康度，反而会导致驱逐线程频繁争夺 ReentrantLock，影响业务线程获取连接的性能。

// 配置示例：每 30 秒执行一次空闲连接检测
spring.datasource.druid.time-between-eviction-runs-millis=30000

// 内部逻辑示意（非实际源码）
while (running) {
    Thread.sleep(timeBetweenEvictionRunsMillis);
    lock.lock();
    try {
        for (DruidConnectionHolder holder : connections) {
            if (holder.isIdle() && 
                (now - holder.getLastActiveTimeMillis()) > minEvictableIdleTimeMillis) {
                closeConnection(holder);
            }
        }
    } finally {
        lock.unlock();
    }
}

4.4 minEvictableIdleTimeMillis：空闲连接的“生存期”

该参数定义了连接在池中保持空闲状态而不被物理关闭的最长时间。当连接的空闲时长超过此阈值，且当前池中连接数大于 minIdle 时，驱逐线程会将其关闭并移除。

在支付订单系统中，数据库连接如果长时间空闲，可能被数据库端（如 MySQL 的 wait_timeout）主动断开，导致连接池中的连接变为“幽灵连接”。合理设置 minEvictableIdleTimeMillis 可以提前清理这些即将失效的连接。

  参数联动关系：

  minEvictableIdleTimeMillis 必须大于 timeBetweenEvictionRunsMillis，否则每次驱逐扫描都会尝试关闭所有空闲连接，造成频繁重建连接的开销。推荐比例：minEvictableIdleTimeMillis ≥ 10 × timeBetweenEvictionRunsMillis。

4.5 三个参数的协同工作流程

下图展示了从连接获取到空闲回收的完整生命周期，以及三个参数在其中的作用位置：

4.6 参数配置对照表（支付场景推荐）

场景	maxWait (ms)	timeBetweenEvictionRunsMillis (ms)	minEvictableIdleTimeMillis (ms)	说明
低并发支付（TPS < 500）	5000	60000	600000	减少驱逐频率，降低 CPU 开销
高并发支付（TPS 1000+）	3000	30000	300000	快速回收空闲连接，避免连接泄漏
对账/批量任务	10000	60000	900000	长事务场景，容忍较长等待

4.7 动态调整实践

Druid 支持通过 DruidDataSource 的 setter 方法在运行时动态修改这三个参数，无需重启应用。在支付订单系统中，可以利用监控数据（如等待队列长度、平均获取连接耗时）触发自动调整：

// 动态调整示例：根据监控指标自动修改参数
@Autowired
private DruidDataSource dataSource;

public void adjustPoolParameters() {
    // 获取当前等待队列长度
    int waitThreadCount = dataSource.getWaitThreadCount();
    
    if (waitThreadCount > 20) {
        // 等待线程过多，适当降低 maxWait 避免雪崩
        dataSource.setMaxWait(2000);
        log.info("动态调整 maxWait 至 2000ms，当前等待线程数：{}", waitThreadCount);
    }
    
    // 获取空闲连接数
    int idleCount = dataSource.getPoolingCount();
    if (idleCount > dataSource.getMaxActive() * 0.7) {
        // 空闲连接过多，缩短驱逐间隔
        dataSource.setTimeBetweenEvictionRunsMillis(20000);
        dataSource.setMinEvictableIdleTimeMillis(180000);
        log.info("动态调整驱逐参数，当前空闲连接数：{}", idleCount);
    }
}

最佳实践： 动态调整应配合监控告警使用。建议在调整前记录原参数值，并设置调整上限/下限，避免参数被调整到极端值导致连接池行为异常。

4.8 参数调优检查清单

maxWait 是否设置为正数？支付系统严禁使用 -1（无限等待）。
timeBetweenEvictionRunsMillis 是否小于数据库 wait_timeout 的一半？避免连接被数据库端提前断开。
minEvictableIdleTimeMillis 是否 ≥ 10 × timeBetweenEvictionRunsMillis？防止频繁无效驱逐。
三个参数是否在配置中心（如 Nacos、Apollo）中可动态修改？便于应急调整。
是否已监控 DruidDataSource.getWaitThreadCount() 和 getNotEmptyWaitCount()？用于判断是否需要调整 maxWait。