基于HiKariCP组件，分析连接池原理

　　池塘里养：Connection；

　　HiKariCP作为SpringBoot2框架的默认连接池，号称是跑的最快的连接池，数据库连接池与之前两篇提到的线程池和对象池，从设计的原理上都是基于池化思想，只是在实现方式上有各自的特点；首先还是看HiKariCP用法的基础案例：

　　HikariDataSource类：汇集数据源描述的相关信息，例如配置、连接池、连接对象、状态管理等；HikariConfig类：维护数据源的配置管理，以及参数校验，例如userName、passWord、minIdle、maxPoolSize等；HikariPool类：提供对连接池与池中对象管理的核心能力，并实现池相关监控数据的查询方法；ConcurrentBag类：抛弃了常规池中采用的阻塞队列作为容器的方式，自定义该并发容器来存储连接对象；PoolEntry类：拓展连接对象的信息，例如状态、时间等，方便容器中追踪这些实例化对象；

　　通过对连接池中几个核心类的分析，也能直观地体会到该源码的设计原理，与上篇总结的对象池应用有异曲同工之妙，只是不同的组件不同的开发者在实现的时候，都具备各自的抽象逻辑。

　　

　　通过配置信息去构建数据源描述，在构造方法中基于配置再去实例化连接池，在HikariPool的构造中，实例化ConcurrentBag容器对象；下面再从源码层面分析实现细节。

　　容器ConcurrentBag类提供PoolEntry类型的连接对象存储，以及基本的元素管理能力，对象的状态描述；虽然被HikariPool对象池类所持有，但是实际的操作逻辑是在该类中；

　　1.1 基础属性

　　其中最为核心的是共享集合、线程级缓存、即时队列；

　　1.2 状态描述

　　在ConcurrentBag类中的IConcurrentBagEntry内部接口，被PoolEntry类实现，该接口定义连接对象的状态：

　　STATE_NOT_IN_USE：未使用，即闲置中；STATE_IN_USE：使用中；STATE_REMOVED：被废弃；STATE_RESERVED：保留态，中间状态，用于尝试驱逐连接对象时；

　　容器的基本能力是用来存储连接对象的，而对象的管理则需要很多扩展的跟踪信息，以有效的完成各种场景下的识别，此时就需要借助包装类的引入；

　　这里需要注意FastList类实现List接口，为HiKariCP组件自定义，相比ArrayList类，出于对性能的追求，在元素的管理时，去掉诸多的范围校验。

　　基于连接池的常规用法，来看看连接对象具体是如何管理，比如被借出，被释放，被废弃等，以及这些操作下对象的状态转换过程；

　　上文加载逻辑的描述中，已经提到在构建数据源的时候，会根据配置实例化连接池，在初始化的时候，基于两个核心切入点来分析源码：1.实例化多少连接对象、2.连接对象转换包装对象；

　　在连接池的构造中执行了方法，在该方法内执行MinIdle最小空闲数的判断，如果大于0，则创建一个包装对象并放入容器中；

　　

　　需要注意两个问题，创建的连接包装对象，初始状态是0即闲置中；另外虽然案例中设置的值，但是这里的判断大于0，也只在容器中预先放入一个空闲对象；

　　从池中获取连接对象时，实际调用的是容器类中的方法：

　　

　　在执行方法时，涉及如下几个核心步骤与逻辑：

　　首先反向遍历本地线程缓存，如果存在空闲连接，则返回该对象；如果没有则寻找共享集合；遍历Shared共享集合前，会标记等待线程数加1，如果存在空闲连接则直接返回；当Shared共享集合中也没有空闲连接时，这时当前线程进行一定时间的队列轮询，可能会有资源的释放，也可能是新添加的资源；

　　注意这里在遍历集合时，取出的对象都会对状态进行判断和更新，如果得到空闲对象，会更新为状态，然后返回；

　　从池中释放连接对象时，实际调用的是容器类中的方法：

　　

　　在释放连接对象时，首先更新对象状态为空闲，然后判断当前是否有等待的线程，在方法中等待线程会进入一定时间的轮询，如果没有的话则把对象放入本地线程缓存中：

　　注意这里涉及到连接对象的状态从使用中转为空闲；与作为连接池中两个核心方法，负责资源创建与回收；

　　最后本篇文章并没有站在HiKariCP组件的整体设计上构思，只是分析连接池这冰山一角，尽管只是部分源码，但是已经足够彰显出作者对于性能的极致追求，比如：本地线程缓存、自定义容器类型、FastList等；能被普遍采用必然存在诸多支撑的理由。

　　举报/反馈