SpringBoot2.0 中 HikariCP 數(shù)據(jù)庫連接池的原理是什么？相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

一、什么是數(shù)據(jù)庫連接池

在講解HiKariCP之前，我們先簡單介紹下什么是數(shù)據(jù)庫連接池（Database Connection Pooling），以及為什么要有數(shù)據(jù)庫連接池。

從根本上而言，數(shù)據(jù)庫連接池和我們常用的線程池一樣，都屬于池化資源，它在程序初始化時創(chuàng)建一定數(shù)量的數(shù)據(jù)庫連接對象并將其保存在一塊內(nèi)存區(qū)中。它允許應用程序重復使用一個現(xiàn)有的數(shù)據(jù)庫連接，當需要執(zhí)行 SQL 時，我們是直接從連接池中獲取一個連接，而不是重新建立一個數(shù)據(jù)庫連接，當 SQL 執(zhí)行完，也并不是將數(shù)據(jù)庫連接真的關掉，而是將其歸還到數(shù)據(jù)庫連接池中。我們可以通過配置連接池的參數(shù)來控制連接池中的初始連接數(shù)、最小連接、較大連接、較大空閑時間等參數(shù)，來保證訪問數(shù)據(jù)庫的數(shù)量在一定可控制的范圍類，防止系統(tǒng)崩潰，同時保證用戶良好的體驗。數(shù)據(jù)庫連接池示意圖如下所示：

因此使用數(shù)據(jù)庫連接池的核心作用，就是避免數(shù)據(jù)庫連接頻繁創(chuàng)建和銷毀，節(jié)省系統(tǒng)開銷。因為數(shù)據(jù)庫連接是有限且代價昂貴，創(chuàng)建和釋放數(shù)據(jù)庫連接都非常耗時，頻繁地進行這樣的操作將占用大量的性能開銷，進而導致網(wǎng)站的響應速度下降，甚至引起服務器崩潰。

二、常見數(shù)據(jù)庫連接池對比分析

這里詳細總結(jié)了常見數(shù)據(jù)庫連接池的各項功能比較，我們重點分析下當前主流的阿里巴巴Druid與HikariCP，HikariCP在性能上是完全優(yōu)于Druid連接池的。而Druid的性能稍微差點是由于鎖機制的不同，并且Druid提供更豐富的功能，包括監(jiān)控、sql攔截與解析等功能，兩者的側(cè)重點不一樣，HikariCP追求極致的高性能。

下面是官網(wǎng)提供的性能對比圖，在性能上面這五種數(shù)據(jù)庫連接池的排序如下：HikariCP>druid>tomcat-jdbc>dbcp>c3p0：

三、HikariCP 數(shù)據(jù)庫連接池簡介

HikariCP 號稱是史上性能好的數(shù)據(jù)庫連接池，SpringBoot 2.0將它設置為默認的數(shù)據(jù)源連接池。Hikari相比起其它連接池的性能高了非常多，那么，這是怎么做到的呢？通過查看HikariCP官網(wǎng)介紹，對于HikariCP所做優(yōu)化總結(jié)如下：

1. 字節(jié)碼精簡 ：優(yōu)化代碼，編譯后的字節(jié)碼量極少，使得CPU緩存可以加載更多的程序代碼；

HikariCP在優(yōu)化并精簡字節(jié)碼上也下了功夫，使用第三方的Java字節(jié)碼修改類庫Javassist來生成委托實現(xiàn)動態(tài)代理.動態(tài)代理的實現(xiàn)在ProxyFactory類，速度更快，相比于JDK Proxy生成的字節(jié)碼更少，精簡了很多不必要的字節(jié)碼。

2. 優(yōu)化代理和攔截器：減少代碼，例如HikariCP的Statement proxy只有100行代碼，只有BoneCP的十分之一；

3. 自定義數(shù)組類型（FastStatementList）代替ArrayList：避免ArrayList每次get()都要進行range check，避免調(diào)用remove()時的從頭到尾的掃描（由于連接的特點是后獲取連接的先釋放）；

4. 自定義集合類型（ConcurrentBag）：提高并發(fā)讀寫的效率；

5. 其他針對BoneCP缺陷的優(yōu)化，比如對于耗時超過一個CPU時間片的方法調(diào)用的研究。

當然作為一個數(shù)據(jù)庫連接池，不能說快就會被消費者所推崇，它還具有非常好的健壯性及穩(wěn)定性。HikariCP從15年推出以來，已經(jīng)經(jīng)受了廣大應用市場的考驗，并且成功地被SpringBoot2.0作為默認數(shù)據(jù)庫連接池進行推廣，在可靠性上面是值得信任的。其次借助于其代碼量少，占用cpu和內(nèi)存量小的優(yōu)點，使得它的執(zhí)行率非常高。最后，Spring配置HikariCP和druid基本沒什么區(qū)別，遷移過來非常方便，這些都是為什么HikariCP目前如此受歡迎的原因。

字節(jié)碼精簡、優(yōu)化代理和攔截器、自定義數(shù)組類型。

四、HikariCP 核心源碼解析

4.1 FastList 是如何優(yōu)化性能問題的

首先我們來看一下執(zhí)行數(shù)據(jù)庫操作規(guī)范化的操作步驟：

• 通過數(shù)據(jù)源獲取一個數(shù)據(jù)庫連接；

• 創(chuàng)建 Statement；

• 執(zhí)行 SQL；

• 通過 ResultSet 獲取 SQL 執(zhí)行結(jié)果；

• 釋放 ResultSet；

• 釋放 Statement；

• 釋放數(shù)據(jù)庫連接。

當前所有數(shù)據(jù)庫連接池都是嚴格地根據(jù)這個順序來進行數(shù)據(jù)庫操作的，為了防止最后的釋放操作，各類數(shù)據(jù)庫連接池都會把創(chuàng)建的 Statement 保存在數(shù)組 ArrayList 里，來保證當關閉連接的時候，可以依次將數(shù)組中的所有 Statement 關閉。HiKariCP 在處理這一步驟中，認為 ArrayList 的某些方法操作存在優(yōu)化空間，因此對List接口的精簡實現(xiàn)，針對List接口中核心的幾個方法進行優(yōu)化，其他部分與ArrayList基本一致 。

首先是get()方法，ArrayList每次調(diào)用get()方法時都會進行rangeCheck檢查索引是否越界，F(xiàn)astList的實現(xiàn)中去除了這一檢查，是因為數(shù)據(jù)庫連接池滿足索引的合法性，能保證不會越界，此時rangeCheck就屬于無效的計算開銷，所以不用每次都進行越界檢查。省去頻繁的無效操作，可以明顯地減少性能消耗。

FastList get()操作

public T get(int index)
{
  // ArrayList 在此多了范圍檢測 rangeCheck(index);
  return elementData[index];
}

其次是remove方法，當通過 conn.createStatement() 創(chuàng)建一個 Statement 時，需要調(diào)用 ArrayList 的 add() 方法加入到 ArrayList 中，這個是沒有問題的；但是當通過 stmt.close() 關閉 Statement 的時候，需要調(diào)用 ArrayList 的 remove() 方法來將其從 ArrayList 中刪除，而ArrayList的remove(Object)方法是從頭開始遍歷數(shù)組，而FastList是從數(shù)組的尾部開始遍歷，因此更為高效。假設一個 Connection 依次創(chuàng)建 6 個 Statement，分別是 S1、S2、S3、S4、S5、S6，而關閉 Statement 的順序一般都是逆序的，從S6 到 S1，而 ArrayList 的 remove(Object o) 方法是順序遍歷查找，逆序刪除而順序查找，這樣的查找效率就太慢了。因此FastList對其進行優(yōu)化，改成了逆序查找。如下代碼為FastList 實現(xiàn)的數(shù)據(jù)移除操作，相比于ArrayList的 remove()代碼， FastList 去除了檢查范圍 和 從頭到尾遍歷檢查元素的步驟，其性能更快。

FastList 刪除操作

public boolean remove(Object element)
{
  // 刪除操作使用逆序查找
  for (int index = size - 1; index >= 0; index--) {
   if (element == elementData[index]) {
     final int numMoved = size - index - 1;
     // 如果角標不是最后一個，復制一個新的數(shù)組結(jié)構
     if (numMoved > 0) {
      System.arraycopy(elementData, index + 1, elementData, index, numMoved);
     }
     //如果角標是最后面的 直接初始化為null
     elementData[--size] = null;
     return true;
   }
  }
  return false;
}

通過上述源碼分析，F(xiàn)astList 的優(yōu)化點還是很簡單的。相比ArrayList僅僅是去掉了rage檢查，擴容優(yōu)化等細節(jié)處，刪除時數(shù)組從后往前遍歷查找元素等微小的調(diào)整，從而追求性能極致。當然FastList 對于 ArrayList 的優(yōu)化，我們不能說ArrayList不好。所謂定位不同、追求不同，ArrayList作為通用容器，更追求安全、穩(wěn)定，操作前rangeCheck檢查，對非法請求直接拋出異常，更符合 fail-fast(快速失敗)機制，而FastList追求的是性能極致。

下面我們再來聊聊 HiKariCP 中的另外一個數(shù)據(jù)結(jié)構 ConcurrentBag，看看它又是如何提升性能的。

4.2 ConcurrentBag 實現(xiàn)原理分析   

當前主流數(shù)據(jù)庫連接池實現(xiàn)方式，大都用兩個阻塞隊列來實現(xiàn)。一個用于保存空閑數(shù)據(jù)庫連接的隊列 idle，另一個用于保存忙碌數(shù)據(jù)庫連接的隊列 busy；獲取連接時將空閑的數(shù)據(jù)庫連接從 idle 隊列移動到 busy 隊列，而關閉連接時將數(shù)據(jù)庫連接從 busy 移動到 idle。這種方案將并發(fā)問題委托給了阻塞隊列，實現(xiàn)簡單，但是性能并不是很理想。因為 Java SDK 中的阻塞隊列是用鎖實現(xiàn)的，而高并發(fā)場景下鎖的爭用對性能影響很大。

HiKariCP 并沒有使用 Java SDK 中的阻塞隊列，而是自己實現(xiàn)了一個叫做 ConcurrentBag 的并發(fā)容器，在連接池（多線程數(shù)據(jù)交互）的實現(xiàn)上具有比LinkedBlockingQueue和LinkedTransferQueue更優(yōu)越的性能。

ConcurrentBag 中最關鍵的屬性有 4 個，分別是：用于存儲所有的數(shù)據(jù)庫連接的共享隊列 sharedList、線程本地存儲 threadList、等待數(shù)據(jù)庫連接的線程數(shù) waiters 以及分配數(shù)據(jù)庫連接的工具 handoffQueue。其中，handoffQueue 用的是 Java SDK 提供的 SynchronousQueue，SynchronousQueue 主要用于線程之間傳遞數(shù)據(jù)。

ConcurrentBag 中的關鍵屬性

// 存放共享元素，用于存儲所有的數(shù)據(jù)庫連接
private final CopyOnWriteArrayList sharedList;
// 在 ThreadLocal 緩存線程本地的數(shù)據(jù)庫連接，避免線程爭用
private final ThreadLocal> threadList;
// 等待數(shù)據(jù)庫連接的線程數(shù)
private final AtomicInteger waiters;
// 接力隊列，用來分配數(shù)據(jù)庫連接
private final SynchronousQueue handoffQueue;

ConcurrentBag 保證了全部的資源均只能通過 add() 方法進行添加，當線程池創(chuàng)建了一個數(shù)據(jù)庫連接時，通過調(diào)用 ConcurrentBag 的 add() 方法加入到 ConcurrentBag 中，并通過 remove() 方法進行移出。下面是 add() 方法和 remove() 方法的具體實現(xiàn)，添加時實現(xiàn)了將這個連接加入到共享隊列 sharedList 中，如果此時有線程在等待數(shù)據(jù)庫連接，那么就通過 handoffQueue 將這個連接分配給等待的線程。

ConcurrentBag 的 add() 與 remove() 方法

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()");
  }
  // 新添加的資源優(yōu)先放入sharedList
  sharedList.add(bagEntry);
 
  // 當有等待資源的線程時，將資源交到等待線程 handoffQueue 后才返回
  while (waiters.get() > 0 && bagEntry.getState() == STATE_NOT_IN_USE && !handoffQueue.offer(bagEntry)) {
   yield();
  }
}
public boolean remove(final T bagEntry)
{
  // 如果資源正在使用且無法進行狀態(tài)切換，則返回失敗
  if (!bagEntry.compareAndSet(STATE_IN_USE, STATE_REMOVED) && !bagEntry.compareAndSet(STATE_RESERVED, STATE_REMOVED) && !closed) {
   LOGGER.warn("Attempt to remove an object from the bag that was not borrowed or reserved: {}", bagEntry);
   return false;
  }
  // 從sharedList中移出
  final boolean removed = sharedList.remove(bagEntry);
  if (!removed && !closed) {
   LOGGER.warn("Attempt to remove an object from the bag that does not exist: {}", bagEntry);
  }
  return removed;
}

同時ConcurrentBag通過提供的 borrow() 方法來獲取一個空閑的數(shù)據(jù)庫連接，并通過requite()方法進行資源回收，borrow() 的主要邏輯是：

• 查看線程本地存儲 threadList 中是否有空閑連接，如果有，則返回一個空閑的連接；

• 如果線程本地存儲中無空閑連接，則從共享隊列 sharedList 中獲取；

• 如果共享隊列中也沒有空閑的連接，則請求線程需要等待。

ConcurrentBag 的 borrow() 與 requite() 方法

// 該方法會從連接池中獲取連接, 如果沒有連接可用, 會一直等待timeout超時
public T borrow(long timeout, final TimeUnit timeUnit) throws InterruptedException
{
  // 首先查看線程本地資源threadList是否有空閑連接
  final List