3. 连接泄漏根因分析：未正确归还连接、事务未提交/回滚、异常路径未释放、连接池耗尽导致请求排队

连接泄漏是搜索服务尾延迟压测波动中最隐蔽、破坏力最强的根因之一。泄漏的本质是：连接对象被业务代码获取后，未按契约归还给连接池，导致池内可用连接数持续下降，最终引发请求排队、超时甚至雪崩。本节从四种典型泄漏模式出发，逐一拆解其发生机理与排查路径。

3.1 四种典型泄漏模式对比

3.2 模式一：未正确归还连接

这是最基础的泄漏模式。在搜索服务中，常见于以下代码片段：

// 错误示例：获取连接后未归还
Jedis jedis = jedisPool.getResource();
try {
    String result = jedis.get("search:cache:key");
    // 业务处理...
    // 缺少 jedis.close() 或 jedisPool.returnResource(jedis)
} catch (Exception e) {
    log.error("查询缓存失败", e);
    // 异常路径也未归还
}

正确的做法是使用 try-with-resources 或 finally 块确保归还：

// 正确示例：使用 try-with-resources 自动归还
try (Jedis jedis = jedisPool.getResource()) {
    String result = jedis.get("search:cache:key");
    // 业务处理...
} catch (Exception e) {
    log.error("查询缓存失败", e);
    // 连接在 try-with-resources 结束时自动归还
}

3.3 模式二：事务未提交/回滚

事务未提交或回滚是数据库连接泄漏的高发区。连接被事务长期持有，直到数据库超时强制断开，期间该连接无法被其他请求复用。

// 错误示例：事务开启后未提交也未回滚
Connection conn = dataSource.getConnection();
try {
    conn.setAutoCommit(false);
    // 执行多条 SQL...
    // 业务异常导致未执行 conn.commit()
    // 也未执行 conn.rollback()
} catch (Exception e) {
    log.error("事务执行失败", e);
    // 缺少 conn.rollback()
} finally {
    // 虽然归还了连接，但事务状态未清理
    conn.close(); // 连接归还时仍处于未提交事务状态
}

事务泄漏的排查要点：

• 数据库端： 查询 SHOW PROCESSLIST 或 pg_stat_activity，观察长时间处于 Idle in transaction 状态的连接。
• 应用端： 在连接池监控中查看 active 连接数是否与事务并发数一致。
• 代码审查： 确保每个 try 块都有对应的 commit 或 rollback，且 finally 块中清理事务状态。

3.4 模式三：异常路径未释放

异常路径泄漏是压测场景下最危险的模式。正常路径的代码经过充分测试，但异常路径往往被忽略。当压测流量触发大量异常时，泄漏速度会急剧上升。

// 错误示例：异常路径未释放连接
public SearchResult search(String query) {
    Connection conn = null;
    try {
        conn = dataSource.getConnection();
        // 执行搜索逻辑...
        if (query == null || query.isEmpty()) {
            throw new IllegalArgumentException("查询参数不能为空");
        }
        // 正常返回...
    } catch (IllegalArgumentException e) {
        log.warn("参数校验失败: {}", query);
        // 此处未释放连接，直接返回
        return SearchResult.empty();
    } finally {
        // 注意：如果异常路径中 return 了，finally 仍会执行
        // 但某些写法可能跳过 finally
        if (conn != null) {
            conn.close(); // 确保释放
        }
    }
}

3.5 模式四：连接池耗尽导致请求排队

当上述三种泄漏模式累积到一定程度，连接池中的可用连接数降为零，新到达的请求必须排队等待。这是尾延迟恶化的直接原因。

3.6 泄漏根因的排查路径

针对上述四种模式，推荐以下排查路径：

1. 监控先行： 在压测过程中持续采集连接池指标（活跃连接数、空闲连接数、等待队列长度、超时次数）。
2. 堆栈快照： 当活跃连接数异常时，执行 jstack 或 arthas thread 抓取线程堆栈，定位持有连接但未归还的线程。
3. 代码审查： 针对堆栈定位到的代码路径，逐行检查连接获取与释放的配对情况，特别关注异常路径和事务边界。
4. 系统验证： 使用 lsof -p <pid> | grep ESTABLISHED 确认应用持有的连接数，与连接池指标交叉验证。
5. 修复验证： 修复后再次压测，确认活跃连接数稳定在预期范围内，尾延迟恢复正常。

3.7 泄漏模式与尾延迟的量化关系

从表中可以看出，连接泄漏对尾延迟的影响是非线性的。当可用连接占比低于 50% 时，P99.9 延迟会急剧恶化，这正是压测波动中“突然跳变”现象的根源。