Design Pattern: Object Pool

Type

Creational Patterns

Name

Object Pool

AKA

Resource Pool

Motivation

Performance can be an important consideration for applications. In some scenarios, object creation is a costly step.

Intent

Avoids cost of initializing objects by maintaining a pool of pre-initialized objects that can be re-used.

Description of Benefits

Can offer a performance boost where:

• object instantiation is expensive
• instances of the class are frequently created
• number of instances at any one time is small

Can make initialization time predictable where it would otherwise be unpredictable (e.g. when squiring resources over a network)

Known Uses

Instantiation of objects that represent:

• database connections
• socket connections
• threads
• large graphic objects

Real-World Illustrations

• Shoe shelf at a bowling club
• Car pooling
• Library

Participants

Reusable: An object used by Client until they it is no longer required.

Client: Uses an instance of Reusable for a limited amount of time

ReusablePool: Manages the collection of Reusable objects by:

• creating new instances of Reusable
• supplying instances of Reusable to Clients

Typical methods induce:

• getInstance: A static method that returns an instance of ReusablePool
• aquireReusable:A method that returns an instance of Reusable
• releaseReusable(Reusable):A method that returns a Reusable to the pool

Basic Implementation (Collaboration)

Object Creation

The Client is responsible for requesting the Reusable from the ReusablePool.

On receiving a request for an object, the ReusablePool will attempt to supply an suitable Reusable.

Object Use

The Client should be unaware that the Reusable can be shared with other Clients:  from the Client‘s point of view, the Reusable can be treated in exactly the same way as an object that has been created in any other way,the only difference being that it must return it to the ReusablePool once it has finished using it.

Object Release

The Client is responsible for returning Reusables to the ReusablePool once it is finished with.

Implementation Details

Resource Loading Strategy

Several strategies are available, for example:

• Eager: A specified number of Reusables are created by the ReusablePool when the ReusablePool is instantiated.
• Lazy: Reusables are not created by the ReusablePool until they are requested by the a Client. Once Reusables are released, they are immediately available for other Clients.
• Hybrid: A specified number of Reusables are created eagerly, but additional Reusables are created lazily.
• Lazy-Expanding: Creates resources lazily, but doesn’t re-use them until the ReusablePool reaches a certain size.
• Eager-Expanding: Creates resources eagerly. Creates additional resources when available objects in the ReusablePool drops below a certain threshold.

Maximum Pool Size

Some implementations may set a maximum number of Reusables in the ReusablePool

Empty Pool

Various strategies can be adopted to handle the situation where a Client requests an instance from the pool, but none is currently available:

Prevent the situation by ensuring that the ReusablePool will always contain enough Reusables.

• Fail to provide Reusable, and inform the Client that none is available
• Create a new Reusable, thus increasing the size of the pool
• Block until another thread to releases an object back into the pool
• Forcible reclaim a Reusable from a low-priority Client

Synchronization

In a multi-threaded environment, careful consideration must be given to synchronisation of methods on the ResourcePool object.

Failed Release

If the Client fails to return a Reusable to the pool, then it will be unavailable to other Clients. To avoid this, the ResourcePool could implement an expiry time for Reusable:
if the Reusable has not actually been used for a certain length of time, it can be made available to other Clients.

Resource Eviction

In some situations, it may be undesirable to hold unused Reusables in the ReusablePool for long periods of time. In this case, it may be desirable to evict Reusables from the ReusablePool if they have not been requested by a Client for a specified length of time.

Recycling Methods

Some types of Reusables may need to be reset to a know state before they can be allocated to another Client. This is the responsibility of the ReusablePool.

Variants

• Sub-pools
• Mixed Pools

Relationship with Other Patterns

ReusablePool is often implemented as a Singleton.

References

• http://www.kircher-schwanninger.de/michael/publications/Pooling.pdf
• http://en.wikipedia.org/wiki/Object_pool
• http://www.oodesign.com/object-pool-pattern.html
• http://sourcemaking.com/design_patterns/object_pool
• http://stackoverflow.com/questions/2510975/c-object-pooling-pattern-implementation
• http://www.developer.com/tech/article.php/626171/Pattern-Summaries-Object-Pool.htm
• http://gameprogrammingpatterns.com/object-pool.html
• http://en.wikipedia.org/wiki/Object_pool_pattern

Advertisements