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
It is simply excellent thought
here…
[…]Design Pattern: Object Pool « All Wrong[…]…