Intermittent HikariCP connection pool exhaustion with leaked connections not reclaimed

Answer

No. HikariCP cannot be configured to automatically evict or reclaim a checked-out connection after leakDetectionThreshold without a pool restart. There is no public configuration option or hook to force reclamation of a connection that is still checked out by an application thread.

A custom reaper that calls internal evictConnection methods is unsafe for production. It can abort in-flight transactions, throw SQLExceptions in the owning application thread, and cause data inconsistency. Those internal APIs are not part of the public API and may change between releases.

Confirmed facts

• leakDetectionThreshold is diagnostic only. When a connection is checked out longer than the threshold HikariCP logs a warning with the acquisition stack trace, but it does not close, evict, or return the connection.
• HikariCP provides no public configuration or extension point to forcibly reclaim a checked-out connection. Reclamation requires the application to close the connection or for the owning thread to terminate.
• Restarting the pool is the only supported way to forcibly discard all checked-out connections.
• Increasing leakDetectionThreshold does not prevent leaks, it only changes when the warning is emitted.

Likely explanation

Intermittent exhaustion is most commonly caused by code paths that fail to close a connection in all branches, e.g., missing try-with-resources, early return before close, or a connection being passed beyond its intended scope and never returned. Under load those paths accumulate checked-out connections until the pool is exhausted.

Steps needed for this case

1. Collect leak evidence. Search application logs for HikariCP "Connection leak detection" warnings and capture the stack trace shown for each leak. The stack trace identifies the code path that acquired the connection.
2. Correlate pool state with traffic. Enable pool metrics and monitor active connections, idle connections, and pending threads over time to confirm exhaustion coincides with the leaks.
3. Audit data access code. Verify every Connection, Statement and ResultSet is closed via try-with-resources or a finally block, and that no connection is stored in fields, passed to async tasks, or returned from methods.

One missing diagnostic detail that changes the recommendation: are the leaked connections associated with a consistent stack trace and a specific endpoint or thread pool that remains alive indefinitely? A repeatable stack trace points to a code fix, while long-running legitimate queries may require query timeouts and separate routing rather than leak fixes.