Using HikariCP
Introduction
HikariCP is a lightweight, high-performance JDBC connection pool used by Spring Boot and many Java services. This chapter adds the Maven dependency, configures HikariConfig, obtains connections through DataSource, and compares performance with raw DriverManager—matching the skills you need in production.
Prerequisites
- Why connection pooling?
- MySQL with
jdbc_demoand theuserstable mysql-connector-jinpom.xml
What Is HikariCP?
HikariCP ("light" in Japanese) focuses on a small codebase and fast borrow/return paths. It implements the standard javax.sql.DataSource interface, so your DAOs stay portable. Alternatives exist (Tomcat JDBC Pool, C3P0), but HikariCP is the default choice for new Java projects.
Adding HikariCP to Your Project
Add the dependency to pom.xml:
<dependency>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
<version>5.1.0</version>
</dependency>HikariCP uses SLF4J for logging. If you do not already have an SLF4J binding, you may see a harmless warning at runtime. You can ignore it for this tutorial or add slf4j-simple.
Reload Maven so the JAR appears on the classpath.
Configuring HikariConfig
Configure the pool programmatically or via a .properties file. The programmatic style is easiest while learning:
Wrap HikariDataSource in try-with-resources at shutdown only (application stop). At runtime you create one HikariDataSource and reuse it for the life of the app.
Properties File (Optional)
src/main/resources/hikari.properties:
jdbcUrl=jdbc:mysql://127.0.0.1:3306/jdbc_demo?useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
username=jdbc_user
password=jdbcpass
maximumPoolSize=10
minimumIdle=2HikariConfig config = new HikariConfig("/hikari.properties");
HikariDataSource dataSource = new HikariDataSource(config);Keep passwords out of Git—use environment variables or external config in production.
Getting Connections from the Pool
// Borrow a connection (fast — reuses TCP session)
try (Connection conn = dataSource.getConnection()) {
// use conn
}
// close() returns connection to the poolgetConnection() on a DataSource is the same method you would call on DriverManager, but the implementation is the pool.
Warning
close() Means "Return to Pool"
Calling close() does not destroy the socket. Holding a connection outside try-with-resources starves other threads.
Refactoring a DAO to Use DataSource
Pass the pool into your DAO instead of URL and password:
Application startup:
HikariDataSource ds = new HikariDataSource(config);
PooledUserDao dao = new PooledUserDao(ds);DriverManager vs HikariCP: Code and Performance
Code difference: replace DriverManager.getConnection(url, user, pass) with dataSource.getConnection() everywhere; inject one shared HikariDataSource at startup.
Performance: micro-benchmark inserting 100 rows:
On a typical developer machine, the pooled version is often 5–10× faster because TCP and auth are reused. The gap grows on higher-latency networks.
Monitoring the Pool
int active = ds.getHikariPoolMXBean().getActiveConnections();
int idle = ds.getHikariPoolMXBean().getIdleConnections();
int total = ds.getHikariPoolMXBean().getTotalConnections();
int waiting = ds.getHikariPoolMXBean().getThreadsAwaitingConnection();If waiting is often greater than zero, increase maximumPoolSize or shorten transactions.
FAQ
Pool exhausted — thread blocks then SQLException?
Every connection is checked out until connectionTimeout. Fix leaks (missing close()) or raise pool size carefully.
New HikariDataSource per HTTP request?
No. Create one pool at startup; share it application-wide.
HikariCP only for MySQL?
No. Change JDBC URL and driver; pool behavior is the same for PostgreSQL, Oracle, etc.
Spring Boot?
spring.datasource.hikari.* configures the same properties; Spring creates the DataSource bean for you.