Object pool lifecycles: reuse without stale state

Reuse creates a lifecycle

Pooling retains objects for later use instead of constructing and discarding each instance repeatedly. The retained memory also retains old state unless reset. Nystrom's object-pool discussion emphasizes initialization, capacity decisions, and references held by inactive objects. [1] A pool should therefore expose a lifecycle contract, not just a bag of instances.

Acquisition and return

Separate creation, acquisition, release, and final destruction. Unity's pool interfaces provide callbacks for these operations; its implementation also distinguishes active from inactive objects and destroys excess returned instances. [2] An inactive-storage limit is not automatically a limit on simultaneously active gameplay objects. Enforce a gameplay limit separately when required.

Worked example

An illustrative projectile pool contains a slot identified by (slot = 7, generation = 12). It launches a projectile, then returns that slot after impact. The next acquisition increments the generation to 13 and resets owner, damage, velocity, remaining lifetime, collision filters, and visual trails.

A delayed timer from the previous projectile still refers to (7, 12). Before applying its callback, compare the handle's generation and active status with the pool. Reject it because the current lifetime is (7, 13). A non-null object reference alone would not distinguish these lifetimes and could destroy the new projectile.

Generation handles need an explicit wraparound policy and do not replace ownership. One owner remains responsible for returning the instance exactly once. Other systems hold bounded observations or validated handles.

Implementation workflow

Write a reset checklist from mutable fields and external registrations. Unsubscribe events, cancel timers, detach ownership links, and clear retained references when releasing. Initialize the next lifetime fully before exposing it to collision or rendering. Account for engine callbacks that activation itself may trigger.

Define exhaustion behavior: reject a cosmetic spawn, grow within a budget, or reserve capacity for critical objects. Do not silently reclaim an active gameplay object unless that behavior is part of the design. Track acquisitions, releases, active high-water marks, retained memory, and allocation fallbacks.

Limits and verification

Pooling may increase retained memory and shift cost into reset work. It does not remove simulation, draw calls, or per-object updates. Benchmark a representative workload before pooling objects that are cheap and infrequently created.

Test reuse after every exit path: normal expiry, collision, scene transition, cancellation, and failed initialization. Exercise double release and delayed callbacks. Verify that an inactive object cannot continue dealing damage or retaining an entire unloaded scene. Lifecycle correctness should remain inspectable even when pooling offers no performance benefit.

Sources

[1] Object Pool — Robert Nystrom, Game Programming Patterns.

[2] Unity object-pool implementation — Unity Technologies.