基於HiKariCP元件,分析連線池原理

語言: CN / TW / HK

池塘裡養:Connection;

一、設計與原理

1、基礎案例

HiKariCP作為SpringBoot2框架的預設連線池,號稱是跑的最快的連線池,資料庫連線池與之前兩篇提到的執行緒池和物件池,從設計的原理上都是基於池化思想,只是在實現方式上有各自的特點;首先還是看HiKariCP用法的基礎案例:

import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;

public class ConPool {
    private static HikariConfig buildConfig (){
        HikariConfig hikariConfig = new HikariConfig() ;
        // 基礎配置
        hikariConfig.setJdbcUrl("jdbc:mysql://127.0.0.1:3306/junit_test?characterEncoding=utf8");
        hikariConfig.setUsername("root");
        hikariConfig.setPassword("123456");
        // 連線池配置
        hikariConfig.setPoolName("dev-hikari-pool");
        hikariConfig.setMinimumIdle(4);
        hikariConfig.setMaximumPoolSize(8);
        hikariConfig.setIdleTimeout(600000L);
        return hikariConfig ;
    }
    public static void main(String[] args) throws Exception {
        // 構建資料來源
        HikariDataSource dataSource = new HikariDataSource(buildConfig()) ;
        // 獲取連線
        Connection connection = dataSource.getConnection() ;
        // 宣告SQL執行
        Statement statement = connection.createStatement();
        ResultSet resultSet = statement.executeQuery("SELECT count(1) num FROM jt_activity") ;
        // 輸出執行結果
        if (resultSet.next()) {
            System.out.println("query-count-result:"+resultSet.getInt("num"));
        }
    }
}

2、核心相關類

  • HikariDataSource類:彙集資料來源描述的相關資訊,例如配置、連線池、連線物件、狀態管理等;
  • HikariConfig類:維護資料來源的配置管理,以及引數校驗,例如userName、passWord、minIdle、maxPoolSize等;
  • HikariPool類:提供對連線池與池中物件管理的核心能力,並實現池相關監控資料的查詢方法;
  • ConcurrentBag類:拋棄了常規池中採用的阻塞佇列作為容器的方式,自定義該併發容器來儲存連線物件;
  • PoolEntry類:拓展連線物件的資訊,例如狀態、時間等,方便容器中追蹤這些例項化物件;

通過對連線池中幾個核心類的分析,也能直觀地體會到該原始碼的設計原理,與上篇總結的物件池應用有異曲同工之妙,只是不同的元件不同的開發者在實現的時候,都具備各自的抽象邏輯。

3、載入邏輯

通過配置資訊去構建資料來源描述,在構造方法中基於配置再去例項化連線池,在HikariPool的構造中,例項化ConcurrentBag容器物件;下面再從原始碼層面分析實現細節。

二、容器分析

1、容器結構

容器ConcurrentBag類提供PoolEntry型別的連線物件儲存,以及基本的元素管理能力,物件的狀態描述;雖然被HikariPool物件池類所持有,但是實際的操作邏輯是在該類中;

1.1 基礎屬性

其中最為核心的是sharedList共享集合、threadList執行緒級快取、handoffQueue即時佇列;

// 共享物件集合,存放資料庫連線
private final CopyOnWriteArrayList<T> sharedList;
// 快取執行緒級連線物件,會被優先使用,避免被爭搶
private final ThreadLocal<List<Object>> threadList;
// 等待獲取連線的執行緒數
private final AtomicInteger waiters;
// 標記是否關閉
private volatile boolean closed;
// 即時處理連線的佇列,當有等待執行緒時,通過該佇列將連線分配給等待執行緒
private final SynchronousQueue<T> handoffQueue;

1.2 狀態描述

在ConcurrentBag類中的IConcurrentBagEntry內部介面,被PoolEntry類實現,該介面定義連線物件的狀態:

  • STATE_NOT_IN_USE:未使用,即閒置中;
  • STATE_IN_USE:使用中;
  • STATE_REMOVED:被廢棄;
  • STATE_RESERVED:保留態,中間狀態,用於嘗試驅逐連線物件時;

2、包裝物件

容器的基本能力是用來儲存連線物件的,而物件的管理則需要很多擴充套件的跟蹤資訊,以有效的完成各種場景下的識別,此時就需要藉助包裝類的引入;

// 業務真正使用的連線物件
Connection connection;
// 最近訪問時間
long lastAccessed;
// 最近借出時間
long lastBorrowed;
// 狀態描述
private volatile int state = 0;
// 是否驅逐
private volatile boolean evict;
// 生命週期結束時的排程任務
private volatile ScheduledFuture<?> endOfLife;
// 連線生成的Statement物件
private final FastList<Statement> openStatements;
// 池物件
private final HikariPool hikariPool;

這裡需要注意FastList類實現List介面,為HiKariCP元件自定義,相比ArrayList類,出於對效能的追求,在元素的管理時,去掉諸多的範圍校驗。

三、物件管理

基於連線池的常規用法,來看看連線物件具體是如何管理,比如被借出,被釋放,被廢棄等,以及這些操作下物件的狀態轉換過程;

1、初始化

上文載入邏輯的描述中,已經提到在構建資料來源的時候,會根據配置例項化連線池,在初始化的時候,基於兩個核心切入點來分析原始碼:1.例項化多少連線物件、2.連線物件轉換包裝物件;

在連線池的構造中執行了checkFailFast方法,在該方法內執行MinIdle最小空閒數的判斷,如果大於0,則建立一個包裝物件並放入容器中;

public HikariPool(final HikariConfig config) ;
private void checkFailFast() {
    final PoolEntry poolEntry = createPoolEntry();
    if (config.getMinimumIdle() > 0) {
        connectionBag.add(poolEntry);
    }
}

需要注意兩個問題,建立的連線包裝物件,初始狀態是0即閒置中;另外雖然案例中設定MinIdle=4的值,但是這裡的判斷大於0,也只在容器中預先放入一個空閒物件;

2、借用物件

從池中獲取連線物件時,實際呼叫的是容器類中的borrow方法:

public Connection HikariPool.getConnection(final long hardTimeout) throws SQLException ;
public T ConcurrentBag.borrow(long timeout, final TimeUnit timeUnit) throws InterruptedException ;

在執行borrow方法時,涉及如下幾個核心步驟與邏輯:

public T borrow(long timeout, final TimeUnit timeUnit) throws InterruptedException
{
    // 遍歷本地執行緒快取
    final List<Object> list = threadList.get();
    for (int i = list.size() - 1; i >= 0; i--) {
       final Object entry = list.remove(i);
       final T bagEntry = weakThreadLocals ? ((WeakReference<T>) entry).get() : (T) entry;
       if (bagEntry != null && bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) { }
    }
    // 增加等待執行緒數
    final int waiting = waiters.incrementAndGet();
    try {
        // 遍歷Shared共享集合
        for (T bagEntry : sharedList) {
           if (bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) { }
        }
        // 一定時間內輪詢handoff佇列
        listener.addBagItem(waiting);
        timeout = timeUnit.toNanos(timeout);
        do {
           final T bagEntry = handoffQueue.poll(timeout, NANOSECONDS);
        } 
    } finally {
        // 減少等待執行緒數
       waiters.decrementAndGet();
    }
}
  • 首先反向遍歷本地執行緒快取,如果存在空閒連線,則返回該物件;如果沒有則尋找共享集合;
  • 遍歷Shared共享集合前,會標記等待執行緒數加1,如果存在空閒連線則直接返回;
  • 當Shared共享集合中也沒有空閒連線時,這時當前執行緒進行一定時間的handoffQueue佇列輪詢,可能會有資源的釋放,也可能是新新增的資源;

注意這裡在遍歷集合時,取出的物件都會對狀態進行判斷和更新,如果得到空閒物件,會更新為IN_USE狀態,然後返回;

3、釋放物件

從池中釋放連線物件時,實際呼叫的是容器類中的requite方法:

void HikariPool.recycle(final PoolEntry poolEntry) ;
public void ConcurrentBag.requite(final T bagEntry) ;

在釋放連線物件時,首先更新物件狀態為空閒,然後判斷當前是否有等待的執行緒,在borrow方法中等待執行緒會進入一定時間的輪詢,如果沒有的話則把物件放入本地執行緒快取中:

public void requite(final T bagEntry) {
    // 更新狀態
    bagEntry.setState(STATE_NOT_IN_USE);
    // 等待執行緒判斷
    for (int i = 0; waiters.get() > 0; i++) {
        if (bagEntry.getState() != STATE_NOT_IN_USE || handoffQueue.offer(bagEntry)) { }
    }
    // 本地執行緒快取
    final List<Object> threadLocalList = threadList.get();
    if (threadLocalList.size() < 50) {
        threadLocalList.add(weakThreadLocals ? new WeakReference<>(bagEntry) : bagEntry);
    }
}

注意這裡涉及到連線物件的狀態從使用中轉為NOT_IN_USE空閒;borrowrequite作為連線池中兩個核心方法,負責資源建立與回收;

最後本篇文章並沒有站在HiKariCP元件的整體設計上構思,只是分析連線池這冰山一角,儘管只是部分原始碼,但是已經足夠彰顯出作者對於效能的極致追求,比如:本地執行緒快取、自定義容器型別、FastList等;能被普遍採用必然存在諸多支撐的理由。

四、參考原始碼

應用倉庫:
https://gitee.com/cicadasmile/butte-flyer-parent

元件封裝:
https://gitee.com/cicadasmile/butte-frame-parent