WhenCare writing an object pool, the programmer has tomust be carefultaken to make sureensure the state of the objects returned to the pool is reset back to a sensible state for the next use of the object., If this is not observed,otherwise the object will oftenmay be in somean state that was unexpected by the client, program andwhich may cause the client programit to fail. The pool is responsible for resetting the objects, not the clients. Object pools full of objects with dangerously stale state are sometimes called object cesspools and regarded as an [[anti-pattern]].
The presence of staleStale state ismay not always be an issue; it becomes dangerous when the presence of stale stateit causes the object to behave differentlyunexpectedly. For example, an object that representsrepresenting authentication details may breakfail if the "successfully authenticated" flag is not reset before it is passed outreused, since it will indicateindicates that a user is correctly authenticated (possibly as someone else) when they haven'tare yet attempted to authenticatenot. However, it will work just fine if you failfailing to reset somea value only used only for debugging, such as the identity of the last authentication server used, may pose no issues.
Inadequate resetting of objects may alsocan cause an information leakleaks. IfanObjects object containscontaining confidential data (e.g. a user's credit card numbers) thatmust isn'tbe cleared before the object isbeing passed to a new clientclients, aotherwise, maliciousthe or buggy clientdata may disclosebe the datadisclosed to an unauthorized party.
If the pool is used by multiple threads, it may need the means to prevent parallel threads from grabbing and trying to reuse the same object in parallel. This is not necessary if the pooled objects are immutable or otherwise thread-safe.
