What concrete downsides and bugs can object pooling introduce, beyond just 'added complexity'?

## Framing People dismiss pooling's cost as 'just complexity', but the failure modes are concrete and recurring. Understanding them is what separates 'pooling sounds smart' from 'pooling is a liability here'. ## 1. Stale state (the reset problem) A freshly `new`-ed object starts in a known, clean state. A *pooled* object was used before, so it may still hold the previous borrower's data. Unless every field is reliably reset on borrow or return, you get: - **Correctness bugs** — leftover values produce wrong results. - **Security/privacy leaks** — request A's data (e.g. a user's token in a reused buffer) is visible to request B. This is a real class of vulnerability in pooled request/response objects. Reset code is easy to get *almost* right and miss a field, and it must be kept in sync as the class evolves. ## 2. Leaks and exhaustion A pool relies on borrowers returning objects. If a code path forgets to return one (e.g. an exception skips the `return-to-pool` call), that object is gone from the pool forever — a **leak**. Over time the pool drains; borrowers then block (if the pool waits) or the pool grows unboundedly, depending on design. Either way it's a reliability bug that a plain `new` could never have. ## 3. Aliasing / lifecycle bugs Because one instance is shared over time: - **Double return** — returning the same object twice puts it in the pool twice; two borrowers get the *same* live object and stomp on each other. - **Use-after-return** — keeping a reference after returning the object, then mutating it, corrupts whatever the next borrower is doing. These are the pooling analogue of double-free/use-after-free bugs in manual memory management — precisely the class of error that GC was supposed to abolish. ## 4. Contention A shared pool needs thread-safe borrow/return: a lock, a concurrent queue, or CAS. Under high allocation rates this synchronization can be the bottleneck — **slower** than the lock-free, per-thread TLAB pointer-bump allocation it replaced. You can spend more time coordinating the pool than you ever spent allocating. ## 5. GC-pressure inversion The subtle one. The generational GC is *optimized* for objects that die young: minor GCs are cheap because they only copy the few live young objects. A pooled object, by design, lives a long time: - It survives repeated minor GCs. - It gets **promoted** to the **old generation**. - Old-generation collections are rarer but more expensive and can cause longer pauses. So pooling can *increase* GC cost: you've taken objects the young-gen collector would have reclaimed for free and parked them in the expensive part of the heap. With many pooled objects holding references, you also enlarge the live set the GC must trace. ## 6. It hides allocation from the optimizer A pooled object necessarily escapes (it's stored in the pool), so the JIT's escape analysis / scalar replacement can't eliminate it. You forfeit an optimization that might have made the allocation disappear entirely. ## When the downsides are acceptable For **expensive or scarce resources** (threads, DB/HTTP connections, large direct buffers), the creation cost is so high that all the above bookkeeping is worth it, and mature libraries (HikariCP, executors, Netty allocators) handle the reset/leak/concurrency hazards carefully. The downsides above are the reason you shouldn't hand-roll pooling for ordinary objects. ## Takeaway Pooling reintroduces manual-memory-management-style bugs (stale state, leaks, double-return, use-after-return), adds contention, and can *worsen* GC by promoting long-lived objects to old gen. Only accept these costs for genuinely expensive/scarce resources, ideally via a battle-tested library.