逐行解读Hikari连接池源码

发布时间：2025-11-05 10:41:26 来源：码上建站 作者：应用开发

作者 | 薛师兄

写在前面

几年前，逐行我最开始接触的解读数据库连接池是 C3P0，后来是连接阿里的 Druid，但随着 Springboot 2.0 选择 HikariCP 作为默认数据库连接池这一事件之后，池源HikariCP 作为一个后起之秀出现在大众的逐行视野中，以其速度快，解读性能高等特点受到越来越多人青睐。连接

在实际开发工作中，池源数据库一直是逐行引发报警的重灾区，而与数据库打交道的解读就是 Hikari 连接池，看懂 Hikari 报警日志并定位异常原因，连接是池源实际工作中必不可少的技能！

本文以 Hikari 2.7.9 版本源码进行分析，逐行带大家理解 Hikari 原理，解读学会处理线上问题！连接

源码地址：​​https://gitee.com/mirrors/hikaricp/tree/HikariCP-2.7.9/​​

1、概念释义

在学习一项技术之前，需要先在宏观的层面去看到它的位置，比如我们今天学习的 HikariCP，它在什么位置？

以 Spring Boot 项目为例，云服务器我们有 Service 业务层，编写业务代码，而与数据库打交道的是 ORM 框架（例如 MyBatis），ORM 框架的下一层是 Hikari 连接池，Hikari 连接池的下一层是 MySQL 驱动，MySQL 驱动的下一层是 MySQL 服务器。理解了这个宏观层次，我们再去学习 Hikari 就不会学的那么稀里糊涂了。

其次，我们需要明白数据库连接池是干什么的？

简单来说，数据库连接池负责分配、管理和释放数据库的连接。有了数据库连接池就可以复用数据库连接，可以避免连接频繁建立、关闭的开销，提升系统的性能。它可以帮助我们释放过期的数据库连接，避免因为使用过期的免费源码下载数据库连接而引起的异常。

至于 Hikari，它是一个“零开销”生产就绪的 JDBC 连接池。库非常轻，大约 130 Kb。

2、配置使用

我们先来看一个线上 Hikari 连接池配置需要哪些参数。

)

() {

();

);

();

();

();

();

();

();

();

();

();

, );

, );

, );

, );

, );

);

官方配置说明：​​https://github.com/brettwooldridge/HikariCP#configuration-knobs-baby​​

3、源码分析

1）分析入口

万事开头难，下载 Hikari 源码到本地后该从哪开始去看呢？不妨从下面两个入口去分析。

)

{

;

2）初始化分析

初始化分析主要有两部分工作，一是校验配置并且会矫正不符合规范的配置；二是实例化 Hikari 连接池。

)

{

();

);

());

);

());

();

校验配置会直接抛异常，大部分坑来源于矫正配置这一步，这会使你的配置不生效。

() {

)) {

);

;

}

) {

);

;

}

)) {

);

;

}

) {

)) {

);

;

}

}

) {

);

;

}

) {

);

;

}

) {

;

}

) {

;

}

通过分析连接池实例化过程，可以看到 Hikari 的作者是多么喜欢用异步操作了，包括空闲线程处理、添加连接、关闭连接、连接泄露检测等。

这一步会创建 1 个 LinkedBlockQueue 阻塞队列，需要明确的是，这个队列并不是实际连接池的队列， 只是用来放置添加连接的请求。

)

{

);

);

;

();

();

) {

());

}

{

());

}

());

);

();

());

);

());

());

);

);

3）获取连接分析

Hikari 的连接获取分为两步，一是调用 connectionBag.borrow() 方法从池中获取连接，这里等待超时时间是 connectionTimeout；二是获取连接后，会主动检测连接是否可用，如果不可用会关闭连接，连接可用的话会绑定一个定时任务用于连接泄露的检测。

很多时候，会在异常日志中看到 Connection is not available 错误日志后携带的 request timed out 耗时远超 connectionTimeout，仔细分析源码这也是合理的。

HikariDataSource

{

()) {

);

}

) {

();

}

;

) {

) {

;

) {

();

());

{

);

();

}

) {

) {

();

}

{

;

}

}

());

}

}

}

();

}

{

);

}

{

();

{

;

{

);

) {

}

();

))) {

);

);

}

{

);

);

}

);

);

);

}

) {

();

);

}

{

();

}

4）空闲连接回收

Hikari 在初始化连接池的时候，就已经开启了一条异步定时任务。该任务每 30 秒执行一次空闲连接回收，代码如下：

{

);

()

{

{

();

();

());

();

();

)) {

,

));

;

();

;

}

)) {

));

}

;

;

()) {

);

;

);

();

) {

)) {

);

;

}

}

}

);

}

) {

);

}

}

5）存活时间处理

Hikari 在创建一个连接实例的时候，就已经为其绑定了一个定时任务用于关闭连接。

()

{

{

();

();

) {

;

;

(

{

)) {

());

}

},

));

}

;

}

) {

));

}

;

}

关闭连接的过程是先将连接实例标记为废弃，这样哪怕因为连接正在使用导致关闭失败，也可以在下次获取连接时再对其进行关闭。

)

{

();

)) {

);

;

}

;

6）连接泄露处理

Hikari 在处理连接泄露时使用到了工厂模式，只需要将连接实例 PoolEntry 传入工厂，即可提交连接泄露检测的延时任务。而所谓的链接泄露检测只是打印 1 次 WARN 日志。

{

;

;

)

{

;

;

}

)

);

}

)

{

;

}

) {

);

);

;

}

}

{

);

;

;

;

;

;

;

{

() {

) {}

() {}

() {}

};

}

)

{

);

();

();

}

()

{

}

)

{

);

}

()

{

;

();

];

);

);

);

}

()

{

);

) {

);

}

}

7）连接池类分析

ConcurrentBag 才是真正的连接池，也是 Hikari “零开销”的奥秘所在。

简而言之，Hikari 通过 CopyOnWriteArrayList + State（状态） + CAS 来避免了上锁。

CopyOnWriteArrayList 存放真正的连接对象，每个连接对象都有四种状态：

比如在获取连接时，通过调用 bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE) 方法解决并发问题。

{

);

;

;

;

;

;

;

;

{

);

);

();

}

{

);

}

) {

;

();

);

();

();

) {

));

{

));

}

}

{

();

) {

);

;

)) {

;

}

}

();

{

) {

)) {

) {

);

}

;

}

}

);

);

{

();

);

)) {

;

}

);

);

;

{

();

}

}

) {

);

) {

)) {

;

) {

));

{

();

}

}

();

);

}

) {

) {

);

);

}

);

)) {

();

}

}

) {

) {

);

;

}

);

) {

);

}

;

}

() {

;

}

) {

);

}

4、报警实战

1）实战一

先来看一个真实的线上报警： 

.

)

)

)

)

)

)

)

)

)

)

.

)

)

)

)

)

)

)

.

)

)

)

)

)

)

)

)

)

)

)

)

)

)

)

)

No operations allowed after connection closed 表示访问了已经被 MySQL 关闭的连接。

request timed out after 6791ms 包含等待连接超时 connectionTimeout（配置 2 秒） 和测试连接可用 validationTimeout（默认 5 秒） 两个时间。

)

{

{

{

);

;

) {

);

}

()) {

) {

);

}

());

}

}

{

);

) {

();

}

}

;

}

) {

);

());

;

}

查看 console.log，存在大量获取到已关闭连接的情况： 

所以推断报警原因是因为获取到已经被数据库关闭的连接。

DBA 反馈数据库的 wait_timeout 是 600 秒，线上配置的 maxLifeTime 是 900 秒，配置有误，更改为 450 秒。

上线后验证 console.log 不再持续打印 Failed to validate connection 日志，并且没有 No operations allowed after connection closed 报警日志。

2）实战二

优化上线后，观察到又发生了几十条报警，并且只集中在 1 台机器： 

.

)

)

)

)

)

)

)

)

)

)

.

)

)

)

)

)

)

)

报警日志中没有 No operations allowed after connection closed，且耗时为 connectionTimeout，推测是没有获取到连接，原因可能有：

机器负载过大有可能引起 IO 夯。

比如存在慢SQL，或者流量太大支撑不住等，连接数实在不够用。

Hikari 提供 HikariPoolMXBean 接口获取连接池监控信息。

开启连接泄露参数后，可在日志中查看。

迁移机器，观察后续情况。

增加 Hikari 连接池监控日志，观察连接池使用情况，进一步再做判断。

比如可以通过一个定时任务，每秒打印连接池相关状态： 

{

;

)

() {

)) {

()) {

();

();

();

();

();

();

,

);

}

}

}

增加连接泄露检测参数，比如可以设置 10 秒： 

作者介绍

薛师兄，在某头部互联网公司担任高级研发工程师，热衷于Java技术栈，对底层原理有独特的追求。

相关文章