Object pool
m |
|||
| Line 12: | Line 12: | ||
*Increase the pool size and create another object | *Increase the pool size and create another object | ||
*Return an exception to the client | *Return an exception to the client | ||
| − | *Block until | + | *Block until an object is returned to the pool |
==Concerns== | ==Concerns== | ||
Revision as of 02:26, 24 September 2009
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.
Contents |
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 object
- Return an exception to the client
- Block until an 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.
