How Fast Can Apache Commons Pool2 Run? A Deep Performance Test

Hardware and Software Setup

Testing performed on a MacBook Pro 16‑inch (2019) with 6‑core CPU and 16 GB RAM, using Groovy with default JVM parameters. The object pool configuration ensures that as long as idle objects are available, performance meets the thread count.

Test Preparation

Two scenarios were evaluated: (1) borrowing objects without waiting for return, and (2) borrowing with a 2 ms artificial wait. The pooled object class FunTesterPooled and factory FunFactory are defined, and the pool is created with GenericObjectPoolConfig (maxIdle = 10, minIdle = 2, maxTotal = thread * 2).

Performance Test Cases

The test runs 3 000 000 operations with 2 threads by default. The main method initializes the pool, synchronizes threads with a CyclicBarrier, records creation counts, executes a Concurrent workload, and finally closes the pool.

Results – No‑Wait Scenario

QPS values remain extremely high, e.g., 1 876 172 QPS with 1 thread, 1 852 364 QPS with 2 threads, and around 1.5 M QPS up to 10 threads, confirming that the pool does not become a bottleneck when objects are readily available.

Results – Wait Scenario

Introducing a 2 ms sleep per operation reduces throughput dramatically. Single‑thread QPS drops to about 410 at 20 threads and falls to roughly 114 QPS at 1 000 threads, indicating contention after about 400 concurrent threads.

Analysis of Bottlenecks

The slowdown appears linked to org.apache.commons.pool2.impl.LinkedBlockingDeque and java.util.concurrent.atomic.AtomicLong, which become performance limits under high concurrency. Despite the decline, the pool still satisfies many performance‑testing needs, and further testing of GenericKeyedObjectPool is planned.