Introduction

When HikariCP logs Apparent connection leak detected, it is warning that a connection was checked out from the pool and held longer than the configured leak-detection threshold. That does not always mean a true permanent leak exists, but it does mean the application is either failing to return a connection promptly or holding it long enough to look suspicious. The next step is to inspect the stack trace and decide whether the issue is a real leak, a long-running query, or a threshold that is too aggressive.

What HikariCP Is Actually Measuring

HikariCP starts a timer when a connection is borrowed from the pool. If that connection is not returned within leakDetectionThreshold milliseconds, HikariCP emits a warning and includes the stack trace where the connection was acquired.

That warning means:

• a connection stayed checked out too long
• the pool suspects code may have forgotten to close it
• the acquisition site is probably shown in the log

It does not automatically mean the connection is gone forever. The connection may still come back later. The message says “apparent” for a reason.

A Real Leak Usually Comes from Missing close()

The classic bug is opening a connection and never closing it.

1Connection conn = dataSource.getConnection();
2PreparedStatement ps = conn.prepareStatement("SELECT * FROM orders");
3ResultSet rs = ps.executeQuery();
4// forgot to close rs, ps, and conn

The correct pattern is try-with-resources so everything is returned reliably even if exceptions occur.

1try (Connection conn = dataSource.getConnection();
2     PreparedStatement ps = conn.prepareStatement("SELECT * FROM orders");
3     ResultSet rs = ps.executeQuery()) {
4
5    while (rs.next()) {
6        System.out.println(rs.getInt("id"));
7    }
8}

This is the first thing to audit when leak warnings appear.

Long Queries Can Look Like Leaks Too

Not every warning means you forgot to close the connection. If the code legitimately holds the connection during a slow query or a long transaction, HikariCP may still flag it once the threshold is exceeded.

That means you should compare:

• the leak detection threshold
• normal query duration
• transaction duration
• application behavior under load

If a report shows that the connection eventually returns cleanly after a slow operation, the threshold may simply be too low for the real workload.

The Stack Trace Is the Main Clue

HikariCP's leak warning usually includes the call stack where the connection was borrowed. That tells you where to start reading code. Focus on:

• service methods that open transactions
• repository code that bypasses framework-managed resource handling
• exception paths that skip cleanup
• async code that holds resources longer than expected

The stack trace is often more useful than pool-size metrics at the start of the investigation.

Frameworks Change the Shape of the Problem

In Spring-based applications, explicit JDBC code is not the only place where leaks can happen. Problems can also come from:

• manual DataSource access outside transaction management
• mixing framework-managed and hand-managed resources
• blocking operations inside transactional methods
• calling remote services while a DB connection is still held

So if you are using Spring, JPA, or a similar framework, the leak may come from transaction scope design rather than from a literal missing close() call.

Example Hikari Configuration

A typical HikariCP configuration might look like this:

spring.datasource.hikari.maximum-pool-size=10
spring.datasource.hikari.leak-detection-threshold=5000

This means HikariCP will warn when a borrowed connection remains out for more than 5 seconds. That can be useful during debugging, but in production it should reflect realistic expectations rather than an arbitrarily tiny number.

Fix the Cause, Not Only the Threshold

Raising leakDetectionThreshold can reduce noise, but it should not be your first response if the code really is leaking connections. Fix the cause first:

• return connections reliably
• shorten transaction scope
• avoid expensive non-database work while holding a connection
• profile slow queries

Only then decide whether the threshold itself also needs adjustment.

Common Pitfalls

The most common mistake is assuming the warning always proves a permanent leak. Sometimes the connection is just held for a long-running operation.

Another mistake is ignoring the stack trace and only tuning pool size or timeout settings. Pool tuning does not fix code that forgets to close resources.

Developers also perform network calls, file I/O, or other slow work inside transactions, which keeps the database connection checked out much longer than necessary.

Summary

• HikariCP leak detection warns when a borrowed connection stays out longer than the configured threshold.
• A real leak often comes from code that does not close JDBC resources properly.
• Slow queries or long transactions can also trigger the warning even without a permanent leak.
• Use the stack trace in the log to find the connection acquisition site.
• Fix resource handling and transaction scope first, then tune the threshold only if needed.