当前位置：首页 > 文章列表 > 文章 > java教程 > HikariCP 连接池耗尽排查：别一上来就把 maximumPoolSize 调大

HikariCP 连接池耗尽排查：别一上来就把 maximumPoolSize 调大

来源：17golang Java频道原创 2026-06-04 13:34:13 0浏览收藏

这篇写一个 Java 后端非常典型的生产故障：Spring Boot 服务突然大量报 Connection is not available, request timed out，接口 p99 飙升，线程堆栈里一片等连接。第一反应如果只是把 maximumPoolSize 从 20 改成 80，通常只是把事故往后推了一点。

本文适用于 Java 17/21、Spring Boot 3.x、HikariCP、MyBatis/JPA 常见服务。资料只用于核对事实：Spring Boot 默认连接池常见实现是 HikariCP，Actuator/Micrometer 能暴露 Hikari 连接池指标。正文按线上排查复盘写，重点是找到连接为什么没有及时归还。

HikariCP 连接池耗尽排查思维导图 — 脑图：池满只是结果，真正要看现象、指标、根因和上线闭环。

业务场景：订单接口突然排队

我们有一个订单详情接口，平时 QPS 不高，但活动页会把它打成热点。服务使用 Spring Boot 3、MyBatis、HikariCP，数据库连接池最大 20。某天活动开始后，接口从 80ms 变成 2s 以上，日志里反复出现获取连接超时。

一开始有人建议把连接池改成 80。这个动作不是绝对不能做，但它应该是容量评估后的结果，不应该是第一反应。连接池满了说明连接被占住了，先要找谁占着、占多久、为什么不回来。

问题复现：把慢点放进事务里

最小复现很简单：开一个 20 大小的池，在 @Transactional 方法里先查订单，再调用一个慢 500ms 的远程接口，最后再更新访问记录。压测一上来，数据库连接并不是只服务 SQL，而是陪着远程接口一起等待。

这个坑很隐蔽，因为代码看起来业务顺序没问题：查订单、查库存、组装返回。但从连接池视角看，事务没结束，连接就不能归还。高峰时每个请求多占 500ms，20 个连接很快全部被占满。

HikariCP 连接池耗尽诊断流程 — 排查流程：从报错和指标开始，再进入线程、SQL 和事务边界。

踩坑原因：连接池不是线程池

很多人会把连接池当成“数据库线程池”，觉得大一点就更能扛。实际上连接池是一个稀缺资源闸口，连接越多，数据库端压力也越大。应用把池调大，数据库未必接得住，锁等待、IO、CPU 都可能继续放大。

HikariCP 的优势是轻量和稳定，但它不会替你修复慢 SQL、长事务、连接泄漏、错误的流式查询关闭方式。池满时先调大参数，就像听到烟雾报警器响了先把电池拆掉。

代码案例：快拿快还，别把远程调用塞进事务

下面的对比是我 review Java 项目时经常指出的问题。坏写法里，事务包住了远程调用；好写法里，数据库操作尽量短，远程补充信息放到事务外，并且连接池参数更强调快速失败和泄漏发现。

HikariCP 连接池配置和代码对比 — 生产目标不是让连接池无限等，而是快失败、快定位、快归还。

@Service
public class OrderQueryService {
    private final OrderMapper orderMapper;
    private final StockClient stockClient;

    public OrderDetail detail(long orderId) {
        Order order = loadOrder(orderId); // 事务短，连接尽快归还
        Stock stock = stockClient.query(order.getSkuId());
        return OrderDetail.of(order, stock);
    }

    @Transactional(readOnly = true)
    public Order loadOrder(long orderId) {
        return orderMapper.selectById(orderId);
    }
}

如果你用 JPA，也要注意懒加载边界。事务外访问懒加载字段会抛异常，事务里做太多事情又会拉长连接占用时间。我的习惯是查询层返回明确 DTO，少把实体对象带着事务上下文到处跑。