hikari简介以及相关的概念

"Simplicity is prerequisite for reliability." - Edsger Dijkstra

hikari，日语中“光”的意思，作者为这个数据库连接池命名为光，寓意是像光一样快。在分析hikariCP之前简单介绍下JDBC和数据库连接池。

JDBC

全称Java Database Connectivity，java入门课本中基本都会介绍到的部分。

以常见的MySQL数据库为例，JDBC可以简单概括为就是一个jar包，这个jar包中提供了相应的interface与class，封装好了与MySQL服务端连接的协议，通过Java代码就可以实现mysql client上的select、update、delete等功能。

JDBC

原始的JDBC使用姿势是这样的（爷青回）：


 try {
    // 初始化驱动类com.mysql.jdbc.Driver
    Class.forName("com.mysql.jdbc.Driver");
    // 获取connection连接
    conn = DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306/test?characterEncoding=UTF-8","root", "admin");

    // 查询
    sql = "select * from test"
    pstmt = (PreparedStatement) conn.prepareStatement(sql);
    rs = (ResultSet) pstmt.executeQuery();
    // 后续将ResultSet转化为对象返回...
} catch (ClassNotFoundException e) { 				
    e.printStackTrace();
}catch (SQLException e) {							
    e.printStackTrace();
}

数据库连接池（Connection Pool）

以上DriverManager.getConnection建立jdbc连接的过程是很昂贵的，需要经历 TCP握手+MySQL认证，如果服务在不断并发处理多个请求的时候每次都重新建立JDBC连接并且在请求结束后关闭JDBC连接，那么将会导致：

网络IO多，因为不断的TCP握手和TCP关闭，大量新建后立刻关闭的TIME_WAIT状态的TCP连接占用系统资源
数据库负载高，数据库也要重新为连接建立各种数据结构，并且在短暂的查询结束后又要销毁
查询耗时长，多了TCP握手和MySQL认证的耗时。同时，不断产生又回收掉JDBC连接资源会频繁触发GC

为了能够 复用已经辛辛苦苦建立好的JDBC连接，就有了数据库连接池的概念，同理线程池、redis连接池、HBase连接池等等都同理。

数据库连接池应该具有的功能

在连接应用启动的时候建立连接，并且保存到Java的容器或自定义的容器中维护
在应用运行的过程中，间歇性测试连接的可用性（select 1），踢出不可用的连接，加入新的连接
在应用结束后关闭JDBC连接

Spring-JDBC

基于以上原JDBC的使用方式可以看出，JDBC在使用上存在大量可以封装起来的功能（connection的获取、构造PreparedStatement、connection的回收等）。总之，Spring-JDBC通过对JDBC的封装，简化了SQL的执行步骤，我们只需要输入sql语句，框架会输出sql的执行结果（类似于mysql-client控制台的效果）。

Spring-JDBC

如上图，有了Spring-JDBC等框架封装JDBC连接获取，prepareStatement赋值，JDBC连接的释放，使用者就只需要写好sql，调用Spring-JDBC提供的JdbcTemplate类封装的方法，等待获取结果即可。

JdbcTemplate类会通过Spring依赖注入等方式设置好它的dataSource属性，而这个dataSource就是一个数据连接池（Connection Pool,CP），CP通过选择合适的数据结构来动态维护着与MySQL的Jdbc连接。整个封装起来对使用者来说无需感知，只需要知道输入SQL语句和输出结果就好。

hikari核心功能

HikariDataSource

HikariDataSource的继承结构

正如上图所示，dataSource代表着一个数据库连接池，而hikari的数据库连接池就是HikariDataSource，这个类是hikari的核心类。

HikariDataSource

HikariDataSource的继承关系如上图，重点关注HikariConfig和DataSource。

DataSource，是一个接口，就是数据库连接池在Java类中的体现，对JDBC框架来说不需要关注Connection怎么来的，只需要调这个接口的方法获取即可
HikariConfig，hikari配置类，有着jdbcUrl、用户名密码、超时时间、数据库连接池连接数等成员变量属性

HikariDataSource的成员结构

HikariDataSource的主要成员结构如下图：

HikariDataSource的结构

isShutdown，一个AtomicBoolean（cas乐观锁）用来标识该dataSource是否已经关闭
fastPathPool 和 pool，都是指向HikariPool结构的引用（Hikari优化用来提升性能的手段）
若干继承自HikariConfig的数据库连接池配置属性

HikariPool

HouseKeeper管家

HikariPool的主要属性如上图所示，主要通过30s执行一次的定时任务HouseKeeper来维护管理连接池中的连接。
HouseKeeper任务执行流程的伪代码如下：

def run():
    # hikari的连接池维护机制大量依赖时间戳，如果发现系统时间倒退了，则会将连接池清空重来
    if detect_retrograde_time():
        softEvictConnections()
        return
    if detect_forward_time(): # 如果发现时间推前了，打日志，警告维持的连接会提前退休
        log()
    if idleTimeout > 0L && config.getMinimumIdle() < config.getMaximumPoolSize():
        # 清理过期连接
        for connection in connectionBag_NotInUse:
            if is_timeout(connection):
                closeConnection(connection)
    # 初始化或清理过后
    fillPool() # 填充连接池，保证最小的连接数量（idleConnections），同时保证不超过最大连接数量（maximumPoolSize）

从伪代码中可以看出，HouseKeeper主要的工作分为：

检测系统时间的准确性，系统时间被用户篡改过，则处理清空连接池
对空闲的连接，根据idleTimeout属性清理过期连接
在初始化或清理过后，填充新的连接到连接池中

关闭连接的过程（closeConnection）和填充的过程（fillPool）则分别是通过向上图中的closeConnectionExecutor和addConnectionExecutor连接池提交异步任务的方式，分别执行JDBC连接关闭和异步的建立JDBC连接的。

hikari优化的连接池存储容器 - ConcurrentBag

通过上面的分析，我们知道了hikari是通过在HikariPool这样的数据结构中执行30s一次的定时任务动态关闭/新增连接到连接池的。维护连接池中的连接就需要用到一种容器，由于新增和关闭连接都是通过线程池异步执行的，而且getConnection()的操作大多数情况下是并发的，必然涉及到支持并发。在Hikari中是通过自定义的容器类ConcurrentBag来维护JDBC连接的。

ConcurrentBag的结构

ConcurrentBag的结构如下图，重点关注

sharedList和threadList，是两个关于PoolEntry（JdbcConnection的封装）的列表，用来实际存储连接池中维护的Jdbc连接
listener，是指向HikariPool的引用，当ConcurrentBag获取连接时发现用完了，则通过listener的回调接口请求HikariPool多扩充点Jdbc连接入池
handoffQueue，和listener相关，HikariPool扩充连接池后将新的连接通过该队列提供给正在等待的线程，正在getConnection的线程会在queue的另一端阻塞住，等待扩充连接后喂给它们

ConcurrentBag的结构

PoolEntry，可以简单理解为Hikari对JdbcConnection的一层封装，有四种状态

int STATE_NOT_IN_USE = 0; 没在用

int STATE_IN_USE = 1; 使用中

int STATE_REMOVED = -1; 已移除

int STATE_RESERVED = -2; 预定

ConcurrentBag#add

新增的接口很简单，这里直接贴出源码。

public void add(final T bagEntry)
   {
      if (closed) {
         LOGGER.info("ConcurrentBag has been closed, ignoring add()");
         throw new IllegalStateException("ConcurrentBag has been closed, ignoring add()");
      }

      sharedList.add(bagEntry);

      // spin until a thread takes it or none are waiting
      while (waiters.get() > 0 && !handoffQueue.offer(bagEntry)) {
         yield();
      }
   }

从代码中可以看出主要的工作分为两步：

sharedList.add()
如果有等待中的线程（正在getConnection），则尝试将新加入的JDBC连接通过队列handoffQueue喂给它

ConcurrentBag#remove

通过cas确保当前这个connection在使用中或被预定，使用中是在getConnection的时候通过探活（select 1）发现连接已经已经失效时，将其关闭；被预定是在HouseKeeper管家第2步对空闲的连接清理的时候，提前将要清理的连接锁住，并且执行close操作时。
sharedList.remove(bagEntry); -- 从list中移除

ConcurrentBag#borrow

borrow方法的伪代码如下。

def borrow():
   if (bagEntry = find_from_threadList()) != null: # 1.优先从threadList中找
       return bagEntry
   waiters++
   try:
       for bagEntry in sharedList: # 2. 从sharedList中找
           if not_in_use(bagEntry):
               if waiters > 1: 
                   # 2.1 如果从sharedList中找到了，但是有waiting的，大概率是在并发情况下抢到了别人的，那就帮他再申请一个JDBC连接
                   listener.addBagItem(waiters - 1);
               return bagEntry
       # 3. sharedList中没找到，则申请新的JDBC连接
       listener.addBagItem(waiting);
       # 4. 申请了新的JDBC连接后，站在handoffQueue的一边，等待JDBC连接创建好的结果
       while(not_timeout()):
           bagEntry = handoffQueue.poll()
           if not_in_use(bagEntry):
               return bagEntry
    finally:
        waiters--

ConcurrentBag、hikari与Spring-JDBC

上面的解释可能太过底层和抽象，基于上面对ConcurrentBag主要方法的源码分析，我们这里可以将hikari的ConcurrentBag与Spring-JDBC整个串起来，分析一条sql语句执行的整个过程。

ConcurrentBag、hikari与Spring-JDBC

以语句select * from xxx为例，

在业务代码层面通过调用Spring-JDBC提供的JdbcTemplate的query方法，获取查询结果
JdbcTemplate调用内部的execute方法时，调用了HikariDataSource#getConnection方法（dataSource可以通过手动注入，或SpringIOC注入）
HikariDataSource通过向其内部维护的连接池对象HikariPool请求getConnection获取连接(注意，这里有两个HikariPool，是hikari的一种优化手段，下文中会详细分析)
HikariPool通过向其内部维护的connectionBag（即ConcurrentBag对象）借用（borrow）来获取连接，借用的过程就是从写时拷贝list sharedList或threadLocal threadList获取连接，最终再一层层返回给JdbcTemplate，由JdbcTemplate执行sql语句，并将最终结果返回给业务代码
在第4步中，可能存在ConcurrentBag中维护的连接不够用的情况，这时候会通过listener指向的HikariPool请求扩充连接池中的连接

综上，我们可以看出，最终一条sql是通过这样层层抽象封装来实现的，

HikariDataSource只是为了对Spring-JDBC的DataSource接口做适配而产生的
HikariPool才是Hikari的核心功能，它像是一个专门负责管理DB连接的管家，背着一个名叫ConcurrentBag的重重的背包，在你（业务侧）需要JDBC连接的时候提供给你，同时管家自己会是不是检查和扩充背包里的连接（就像跟女神和高富帅一起爬山时跟在最后背包的工具人）泪目( Ĭ ^ Ĭ )

工具人

Hikari的优化点

通过上面的分析，读者应该已经清楚了Hikari的大致原理，有了大致的了解之后，Hikari的代码实现的很多细节通过阅读源码也可以细化了解。我们这里回到最关键的问题，Hikari为什么这么快，为什么敢用光来命名自己。

字节码精简

字节码精简：优化代码，直到编译后的字节码最少，这样，CPU缓存可以加载更多的程序代码；优化代理和拦截器：减少代码，例如HikariCP的Statement proxy只有100行代码，只有BoneCP的十分之一

以上是从网上搜到的，确实可以体现出Hikari极致优化的特性，但是对性能影响可能微乎其微。

fastPathPool 和 pool

如上面关于HikariDataSource与HikariPool的关系时，我们可以看到HikariDataSource内部有两个指向HikariPool的引用。这里也是Hikari优化性能的一种手段。

fastPathPool 和 pool

HikariDataSource有两种初始化的方式：

一种是无参数的初始化方式，这种时候当执行到getConnection的时候，会通过 懒汉单例模式 懒加载初始化HikariPool，赋值给pool引用，懒汉模式涉及到并发情况，所以一般会考虑采用 Double-Check-Lock（DCL） 方式加锁，DCL方式中涉及到JVM的字节码指令重排优化的问题，所以需要将pool引用设置为volatile，废弃掉JVM的字节码指令优化。（【5】Java中DCL(Double-Check-Lock)对volatile必要性的疑惑）但是同时因为volatile关键字，导致pool相关的加载都会有性能问题。所以获取HikariPool时优先通过fastPathPool引用。
另一种是带参数的初始化，在构造函数中同时将初始化完的HikariPool赋值给pool和fastPathPool引用，在获取HikariPool引用的时候总是优先获取fastPathPool，以防止volatile关键字对性能的影响

自定义的容器类型

1、定义数组类型（FastStatementList）代替ArrayList：避免每次get()调用都要进行range check，避免调用remove()时的从头到尾的扫描；【6】【追光者系列】HikariCP源码分析之FastList

2、自定义集合类型（ConcurrentBag）：提高并发读写的效率；
通过之前对ConcurrentBag的borrow方法的了解，我们知道，hikariPool是通过ConcurrentBag#borrow方法来获取连接的，而ConcurrentBag中的逻辑则是：优先从threadList（ThreadLocal）获取；获取不到时再从sharedList（CopyOnWriteArrayList）获取

ThreadLocal：例如业务代码执行了两次SQL，获取了两次JDBC连接，在第一次执行完毕之后ConcurrentBag会回收该连接，但是会回收到ThreadLocal中。当业务代码第二次执行SQl需要获取JDBC连接时，只要是同一个线程，则会从ThreadLocal中获取到连接。（关于ThreadLocal的原理，可以参考笔者的往期文章【7】图解分析ThreadLocal的原理与应用场景） threadList

CopyOnWriteArrayList：写时拷贝技术，并发情况下线程安全版本的ArrayList，写时拷贝技术源自于unix系统的fork系统调用，指的是读操作时不加锁，只有当写操作执行的时候锁住整个list，然后执行替换（狸猫换太子）

CopyOnWriteArrayList

扩展知识

事务管理器transactionManager

在需要支持事务操作的方法上，我们通常会加上这样的注解， @Transactional(rollbackFor = Exception.class, value = "txManagerXXX")，用来表示注解包裹住的方法内部是一个事务，需要符合事务的特性（如原子性）在Spring中的实现是通过AOP切面技术生成了动态代理，封装了@Transactional注解的方法 transactionManager

JNDI

JNDI，全称是 Java Naming and Directory Interface，Java 命名与目录接口，也是跟原始的JDBC用法息息相关的概念。数据库的实现有很多种，Java服务是通过JDBC驱动类来获取JDBC连接的，那么原始的JDBC用法就会有几种问题：

数据库的地址、账户名、密码、连接池的参数发生改变，要修改代码
数据库可能从MySQL改为Oracle或者其它DB，需要修改底层代码，换JDBC驱动jar包，由此会引发一系列的相关功能的回归

基于以上问题，J2EE规范提出了JNDI的规范，对于业务代码来说只需要关心获取的DataSource是哪个（通过naming-名字），不需要知道这个DataSource背后的细节（url地址、账户名密码等），即findResouceByName，而resources的相关参数是配置在xml文件里的。
经常用Spring的读者可以看出，这就是SpringIOC容器提供的getBean(String beanName)方法，即Spring的xml文件，所以SpringIOC就是在J2EE的规范上实现的。（【8】Spring IOC 前世今生之 JDNI - binarylei - 博客园）

hikari数据库连接池源码分析与相关概念

hikari简介以及相关的概念

JDBC

数据库连接池（Connection Pool）

数据库连接池应该具有的功能

Spring-JDBC

hikari核心功能

HikariDataSource

HikariDataSource的继承结构

HikariDataSource的成员结构

HikariPool

HouseKeeper管家

hikari优化的连接池存储容器 - ConcurrentBag

ConcurrentBag的结构

ConcurrentBag#add

ConcurrentBag#remove

ConcurrentBag#borrow

ConcurrentBag、hikari与Spring-JDBC

Hikari的优化点

字节码精简

fastPathPool 和 pool

自定义的容器类型

扩展知识

事务管理器transactionManager

JNDI

references