HiKariCP 号称是业界跑得最快的数据库连接池，这两年发展得顺风顺水，尤其是 Springboot 2.0 将其作为了默认的数据库连接池后，江湖一哥的地位已是毋庸置疑了。那它为什么那么快呢？

HiKariCP 官方网站解释了其性能之所以如此之高的秘密。微观上 HiKariCP 程序编译出的字节码执行效率更高，站在字节码的角度去优化 Java 代码，HiKariCP 的作者对性能的执着可见一斑，不过遗憾的是他并没有详细解释都做了哪些优化。而宏观上主要是和两个数据结构有关，一个是 FastList，另一个是 ConcurrentBag。下面我们来看看它们是如何提升 HiKariCP 的性能的。

FastList

按照规范步骤，执行完数据库操作之后，需要依次关闭 ResultSet、Statement、Connection，但是总有粗心的同学只是关闭了 Connection，而忘了关闭 ResultSet 和 Statement。为了解决这种问题，最好的办法是当关闭 Connection 时，能够自动关闭 Statement。为了达到这个目标，Connection 就需要跟踪创建的 Statement，最简单的办法就是将创建的 Statement 保存在数组 ArrayList 里，这样当关闭 Connection 的时候，就可以依次将数组中的所有 Statement 关闭。

HiKariCP 觉得用 ArrayList 还是太慢，当通过 conn.createStatement() 创建一个 Statement 时，需要调用 ArrayList 的 add() 方法加入到 ArrayList 中，这个是没有问题的；但是当通过 stmt.close() 关闭 Statement 的时候，需要调用 ArrayList 的 remove() 方法来将其从 ArrayList 中删除，这里是有优化余地的。

假设一个 Connection 依次创建 6 个 Statement，分别是 S1、S2、S3、S4、S5、S6，按照正常的编码习惯，关闭 Statement 的顺序一般是逆序的，关闭的顺序是：S6、S5、S4、S3、S2、S1，而 ArrayList 的 remove(Object o) 方法是顺序遍历查找，逆序删除而顺序查找，这样的查找效率就太慢了。如何优化呢？很简单，优化成逆序查找就可以了。
image.png
HiKariCP 中的 FastList 相对于 ArrayList 的一个优化点就是将 remove(Object element) 方法的查找顺序变成了逆序查找。除此之外，FastList 还有另一个优化点，是 get(int index) 方法没有对 index 参数进行越界检查，HiKariCP 能保证不会越界，所以不用每次都进行越界检查。整体来看，FastList 的优化点还是很简单的。下面我们再来聊聊 HiKariCP 中的另外一个数据结构 ConcurrentBag，看看它又是如何提升性能的。

ConcurrentBag

如果让我们自己来实现一个数据库连接池，最简单的办法就是用两个阻塞队列来实现，一个用于保存空闲数据库连接的队列 idle，另一个用于保存忙碌数据库连接的队列 busy；获取连接时将空闲的数据库连接从 idle 队列移动到 busy 队列，而关闭连接时将数据库连接从 busy 移动到 idle。这种方案将并发问题委托给了阻塞队列，实现简单，但性能不好。因为 Java 阻塞队列是用锁实现的，而高并发场景下锁的争用对性能影响很大。

  1. // 忙碌队列
  2. BlockingQueue<Connection> busy;
  3. // 空闲队列
  4. BlockingQueue<Connection> idle;

HiKariCP 并没有使用 Java SDK 中的阻塞队列，而是自己实现了一个叫做 ConcurrentBag 的并发容器。ConcurrentBag 的设计最初源自 C#，它的一个核心设计是使用 ThreadLocal 避免部分并发问题，不过 HiKariCP 中的 ConcurrentBag 并没有完全参考 C# 的实现，下面我们来看看它是如何实现的。

ConcurrentBag 中最关键的属性有 4 个，分别是：用于存储所有的数据库连接的共享队列 sharedList、线程本地存储 threadList、等待数据库连接的线程数 waiters 以及分配数据库连接的工具 handoffQueue。其中，handoffQueue 用的是 Java 提供的 SynchronousQueue，主要用于线程之间传递数据。

  1. // 用于存储所有的数据库连接
  2. CopyOnWriteArrayList<T> sharedList;
  4. // 线程本地存储中的数据库连接
  5. ThreadLocal<List<Object>> threadList;
  7. // 等待数据库连接的线程数
  8. AtomicInteger waiters;
  10. // 分配数据库连接的工具
  11. SynchronousQueue<T> handoffQueue;

1. add

当线程池创建了一个数据库连接时，通过调用 ConcurrentBag 的 add() 方法加入到 ConcurrentBag 中，下面是 add() 方法的具体实现，逻辑很简单，就是将这个连接加入到共享队列 sharedList 中，如果此时有线程在等待数据库连接，那么就通过 handoffQueue 将这个连接分配给等待的线程。

  1. // 将空闲连接添加到队列
  2. void add(final T bagEntry){
  3.   // 加入共享队列
  4.   sharedList.add(bagEntry);
  5.   // 如果有等待连接的线程，
  6.   // 则通过handoffQueue直接分配给等待的线程
  7.   while (waiters.get() > 0 
  8.     && bagEntry.getState() == STATE_NOT_IN_USE 
  9.     && !handoffQueue.offer(bagEntry)) {
  10.       yield();
  11.   }
  12. }

2. borrow

通过 ConcurrentBag 提供的 borrow() 方法，可以获取一个空闲的数据库连接，borrow() 的主要逻辑是：

  • 首先查看线程本地存储是否有空闲连接，如果有，则返回一个空闲的连接；
  • 如果线程本地存储中无空闲连接，则从共享队列中获取。
  • 如果共享队列中也没有空闲的连接，则请求线程需要等待。

需要注意的是，线程本地存储中的连接是可以被其他线程窃取的，所以需要用 CAS 方法防止重复分配。在共享队列中获取空闲连接，也采用了 CAS 方法防止重复分配。

  1. T borrow(long timeout, final TimeUnit timeUnit){
  2.   // 先查看线程本地存储是否有空闲连接
  3.   final List<Object> list = threadList.get();
  4.   for (int i = list.size() - 1; i >= 0; i--) {
  5.     final Object entry = list.remove(i);
  6.     final T bagEntry = weakThreadLocals 
  7.       ? ((WeakReference<T>) entry).get() 
  8.       : (T) entry;
  9.     // 线程本地存储中的连接也可以被窃取，
  10.     // 所以需要用CAS方法防止重复分配
  11.     if (bagEntry != null 
  12.       && bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) {
  13.       return bagEntry;
  14.     }
  15.   }
  17.   // 线程本地存储中无空闲连接，则从共享队列中获取
  18.   final int waiting = waiters.incrementAndGet();
  19.   try {
  20.     for (T bagEntry : sharedList) {
  21.       // 如果共享队列中有空闲连接，则返回
  22.       if (bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) {
  23.         return bagEntry;
  24.       }
  25.     }
  26.     // 共享队列中没有连接，则需要等待
  27.     timeout = timeUnit.toNanos(timeout);
  28.     do {
  29.       final long start = currentTime();
  30.       final T bagEntry = handoffQueue.poll(timeout, NANOSECONDS);
  31.       if (bagEntry == null 
  32.         || bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) {
  33.           return bagEntry;
  34.       }
  35.       // 重新计算等待时间
  36.       timeout -= elapsedNanos(start);
  37.     } while (timeout > 10_000);
  38.     // 超时没有获取到连接，返回null
  39.     return null;
  40.   } finally {
  41.     waiters.decrementAndGet();
  42.   }
  43. }

3. requite

释放连接需要调用 ConcurrentBag 提供的 requite() 方法，该方法的逻辑很简单，首先将数据库连接状态更改为 STATE_NOT_IN_USE，之后查看是否存在等待线程，如果有，则分配给等待线程；如果没有，则将该数据库连接保存到线程本地存储里。

  1. // 释放连接
  2. void requite(final T bagEntry){
  3.   // 更新连接状态
  4.   bagEntry.setState(STATE_NOT_IN_USE);
  5.   // 如果有等待的线程，则直接分配给线程，无需进入任何队列
  6.   for (int i = 0; waiters.get() > 0; i++) {
  7.     if (bagEntry.getState() != STATE_NOT_IN_USE 
  8.       || handoffQueue.offer(bagEntry)) {
  9.         return;
  10.     } else if ((i & 0xff) == 0xff) {
  11.       parkNanos(MICROSECONDS.toNanos(10));
  12.     } else {
  13.       yield();
  14.     }
  15.   }
  16.   // 如果没有等待的线程，则进入线程本地存储
  17.   final List<Object> threadLocalList = threadList.get();
  18.   if (threadLocalList.size() < 50) {
  19.     threadLocalList.add(weakThreadLocals 
  20.       ? new WeakReference<>(bagEntry) 
  21.       : bagEntry);
  22.   }
  23. }

HiKariCP 中的 FastList 和 ConcurrentBag 这两个数据结构使用得非常巧妙，虽然实现起来并不复杂，但是对于性能的提升非常明显，根本原因在于这两个数据结构适用于数据库连接池这个特定的场景。FastList 适用于逆序删除场景；而 ConcurrentBag 通过 ThreadLocal 做一次预分配，避免直接竞争共享资源，非常适合池化资源的分配。