When is applying the Object Pool pattern the wrong choice, and what alternatives address the same cost without pooling?

## The precondition for pooling Pooling pays off only when: ``` cost(construct + destroy) >> cost(pool bookkeeping + reset + contention) ``` and the object is genuinely reusable. If either side fails, the pattern is a net negative — and it always adds bug surface: leaks, cross-lease contamination, exhaustion tuning, double release. ## Case 1: cheap in-memory objects on a managed runtime On a generational garbage collector, allocation is typically a **pointer bump** in a thread-local allocation buffer — a handful of instructions with no lock. Objects that die young are reclaimed by copying the survivors only; the dead cost literally nothing to collect. Pooling such objects makes things worse in three ways: 1. **Synchronization** on the pool's data structure, where allocation had none. 2. **Generational promotion**: pooled objects survive many collections and get promoted to the old generation, where reclamation is far more expensive and where they add to the tracing set forever. 3. **Write barriers / cross-generational references**: an old-generation pooled object that points at a fresh young object forces remembered-set bookkeeping on every store, adding cost to the very code that uses it. The historical example is String/Integer-style "object caches" in Java, widely recommended in the 1990s and considered an anti-pattern once generational collectors matured. The residue survives as small interning caches for values, which are about identity/memory, not construction cost. **Still worth pooling on managed runtimes**: large arrays and buffers (multi-megabyte allocations that would go straight to a humongous/large-object region and drive full collections), off-heap or native memory, and anything wrapping an OS handle. ## Case 2: the pool becomes the contention point A pool with a single global lock turns parallel work into serialized work. When acquire/release rates reach millions per second, the pool's own lock costs more than the object ever did. Mitigations, in order of increasing complexity: - **Thread-local instance**: no sharing, no locking, no contention — at the price of `threads × object size` memory and the need to clear per-use state anyway. - **Striped / per-core pools** with a shared overflow: mostly-uncontended fast path, global fallback under imbalance. - **Lock-free structures** (Treiber stack, MPMC queue) — better, but still cache-line ping-pong on the head pointer under heavy contention. This is why runtimes ship things like per-thread arena allocators and pooled allocators with per-thread caches rather than one global pool. ## Case 3: the object is stateless or thread-safe — just share one If an instance has no per-use mutable state, a single long-lived instance serves everyone with no pool at all: HTTP clients, serializers, and many SDK clients are designed to be shared and internally manage their own connections. Creating (or pooling!) one per request is a common and costly mistake — and the shared-client design often already contains a connection pool internally. If state exists but is immutable, share it: that is Flyweight, not Object Pool. ## Case 4: multiplexing beats pooling With HTTP/2, HTTP/3, gRPC, or any protocol supporting concurrent streams over one connection, N concurrent requests do **not** need N connections. Pooling connections there wastes server resources and gains nothing; you want one (or a small number of) connections with many in-flight streams. Pooling is the right answer for strictly request/response, one-at-a-time protocols — which is exactly what a database wire protocol usually is. ## Case 5: someone else pools better For databases, an external pooler (pgbouncer, ProxySQL, RDS Proxy) can pool across *all* application instances. Per-instance pools multiply: 50 replicas × 20 connections = 1000 connections, far past what many database servers handle well. In serverless or highly elastic environments, where instances are numerous and short-lived, per-instance pooling is close to useless and a shared proxy is the correct architecture. ## Case 6: reset cannot be made safe If you cannot prove the object is scrubbed between leases — unbounded session state, arbitrary user code touching it, security context you cannot enumerate — the correct decision may be not to recycle at all. Correctness outranks the saved milliseconds. ## The decision checklist 1. Have I **measured** that construction is a material share of the operation's cost? 2. Does the object wrap an **external, limited** resource (socket, handle, thread, native memory)? 3. Can I **fully reset** its state between leases, or safely destroy it when unsure? 4. Will the pool's own synchronization cost less than what it saves? 5. Is there a **simpler** answer: one shared thread-safe instance, a thread-local, multiplexing, a cheaper constructor, or an external pooler? Only if 1–4 pass and 5 has no better option is Object Pool the right tool. And when it is right (database connections, threads, big buffers), it is usually *very* right — this is not an argument against pooling, only against reflexive pooling.