Why HikariCP Is So Fast: A Deep Dive into Its Implementation

After Spring Boot 2.0 made HikariCP the default JDBC connection pool, HikariCP gained attention for its speed. This article investigates the reasons behind its high performance.

Connection pool technology is a buffering technique that creates and manages reusable connections. It consists of three parts: pool creation, connection usage management, and pool shutdown. The core idea is connection reuse, which can apply to database connections and other resources.

HikariCP overview – the project’s README describes it as a fast, simple, reliable, "zero‑overhead" production‑ready JDBC pool, only about 130 KB in size.

Why HikariCP is fast

Two HikariPool objects: one final instance (fastPathPool) avoids lazy initialization, and a volatile instance (pool) for fallback.

FastList replaces ArrayList , removing range‑check logic and scanning from the tail when removing, which matches the typical open‑close order of connections.

A custom concurrent collection ConcurrentBag provides lock‑free performance.

Getting a connection in the same thread uses a ThreadLocal cache, eliminating contention.

Bytecode is trimmed using Javassist to generate lightweight dynamic proxies.

HikariCP internals

Typical usage starts with Maven dependency:

<dependency>
    <groupId>com.zaxxer</groupId>
    <artifactId>HikariCP</artifactId>
    <version>4.0.3</version>
</dependency>

Configuration and a simple test method illustrate creating a HikariConfig , building a HikariDataSource , obtaining a Connection , executing a query, and finally closing resources.

HikariDataSource implements DataSource . It has two constructors: a no‑arg constructor that leaves fastPathPool null, and a constructor that accepts a HikariConfig and creates both fastPathPool and pool via new HikariPool(this) . Using the latter is recommended for better performance.

The HikariPool class initializes a ConcurrentBag for connection storage, a SuspendResumeLock , thread pools for adding and closing connections, and a scheduled HouseKeeper task that periodically calls fillPool() to maintain the minimum number of connections.

Connection creation flow:

private PoolEntry createPoolEntry() {
    return new PoolEntry(newConnection(), this, isReadOnly, isAutoCommit);
}

The PoolEntry wraps a real JDBC Connection and is stored in the ConcurrentBag . When a thread calls getConnection() , it first checks fastPathPool , then falls back to pool . If the pool is null, double‑checked locking creates it.

Borrowing a connection uses connectionBag.borrow(timeout, MILLISECONDS) . The algorithm first tries a thread‑local cache, then the shared CopyOnWriteArrayList , and finally a blocking queue, ensuring fast local access and fair hand‑off when threads are waiting.

Releasing a connection calls connection.close() , which triggers ProxyConnection.close() . This method closes any open statements stored in a FastList , then recycles the connection back to the pool via connectionBag.requite(poolEntry) . The recycle logic updates the state, hands the connection to waiting threads, or stores it in the thread‑local cache (up to 50 entries).

FastList vs. ArrayList

FastList removes the range‑check in get() , reducing overhead.

Removal scans from the tail, matching the typical LIFO pattern of connection usage.

Summary

The source‑code analysis reveals many small but impactful optimizations—dual pool instances, lock‑free collections, thread‑local caching, and streamlined data structures—that together make HikariCP exceptionally fast. Paying attention to such details can greatly improve the performance of Java backend systems.