先确认连接泄漏的核心依据 #

• 执行Doris FE内置命令SHOW PROC '/connections';，查看连接列表：如果发现大量长时间处于Idle状态的连接，或连接总数持续增长不回落，可实锤连接泄漏
• 核对客户端应用日志，重点排查查询完成后未关闭Connection/Statement的代码路径，尤其是异常触发的分支

核心修复方案 #

1. 用自动资源释放语法杜绝泄漏 #

在客户端代码中强制使用try-with-resources（以Java为例），确保连接、语句、结果集在代码块结束后自动释放，无需手动在finally中关闭：

try (Connection conn = dorisConnectionPool.getConnection();
     PreparedStatement pstmt = conn.prepareStatement("SELECT * FROM your_table WHERE id = ?");
     ResultSet rs = pstmt.executeQuery()) {
    // 业务逻辑处理
} catch (SQLException e) {
    // 异常捕获与处理
}

2. 排查异常分支的资源遗漏 #

检查所有可能抛出异常的代码段：比如catch块中是否未关闭已打开的连接，或者在return前未释放资源，这类场景是连接泄漏的高发区。

3. 优化连接池配置（辅助修复） #

仅调大connection_pool_max_size是治标不治本，配合以下配置从根源减少无效连接占用：

• 设置connection_timeout：比如配置为10秒，超过时间未获取到连接直接抛出异常，避免线程无限阻塞
• 设置idle_timeout：比如配置为300秒，自动回收闲置超过5分钟的连接，释放连接池资源
• 开启连接池的testOnBorrow：获取连接前先校验连接有效性，避免使用已失效的连接

4. 添加连接池监控 #

在应用中接入连接池监控，实时采集活跃连接数、闲置连接数、连接获取耗时等指标，一旦连接数异常增长，可快速定位泄漏代码模块

临时应急措施 #

• 紧急重启客户端应用，快速释放所有泄漏的连接，恢复服务可用性
• 在Doris FE侧确认connection_max_idle_time配置（默认300秒），确保FE主动回收长时间闲置的客户端连接

内容的提问来源于stack exchange，提问作者Michael