Revision as of 04:49, 18 November 2010

The object pool design pattern can be used to aid performance when objects are expensive to create, by using caching. An object pool, usually implemented as a Singleton class, manages a pool of objects that have already been instantiated. Clients can request objects from the pool instead of creating them and return them once they are done with them.

An object pool should be considered when:

• There is a high cost of creating new objects of a particular type
• The rate of instantiation is high
• The number of instantiations in use at a particular time is low

Care should be taking not to use Premature optimization when considering this pattern, and also to avoid creating an Object cesspool.

>==Structure==

Figure - Generic structure of the Object Pool

Intent

The Object Pool pattern manages the reuse of objects when there is a limit on the number of objects to be created, or it is expensive to create.

Solution

The Client calls ReusablePool's aquireReusable method when it wants a Reusable object.

Empty pools

When all available objects are already allocated and a request is made one of several strategies can be utilised:

• Increase the pool size and create another Reusable object
• Return an exception to the Client
• Block until a Reusable object is returned to the pool

Concerns

Some concerns have be expressed about programs that implement very large object pools in languages with dynamic garbage collection. Object pools can also increase the average memory footprint of an application. The theory is that the large number of objects in the pool slow garbage collection routines even when the objects are not in use thus negatively impacting performance.

To address this issue, limit the number of objects that can be created.

Related patterns

• Singleton
• Flyweight

See Also

• Object cesspool
• Identity map pattern