Object pool pattern

Object pool pattern
For the article about a general pool see Pool (Computer science)

In computer programming, an object pool is a software design pattern. An object pool is a set of initialised objects that are kept ready to use, rather than allocated and destroyed on demand. A client of the pool will request an object from the pool and perform operations on the returned object. When the client has finished with an object, it returns it to the pool, rather than destroying it. It is a specific type of factory object.

Object pooling can offer a significant performance boost in situations where the cost of initializing a class instance is high, the rate of instantiation of a class is high, and the number of instances in use at any one time is low. The pooled object is obtained in predictable time when creation of the new objects (especially over network) may take variable time.

However these benefits are mostly true for objects which are expensive with respect to time, such as database connections, socket connections, threads and large graphic objects like fonts or bitmaps. In certain situations, simple object pooling (which hold no external resources, but only occupy memory) may not be efficient and could decrease performance [1].


Handling of empty pools

Object pools employ one of three strategies to handle a request when there are no spare objects in the pool.

  1. Fail to provide an object (and return an error to the client).
  2. Allocate a new object, thus increasing the size of the pool. Pools that do this usually allow you to set the high water mark (the maximum number of objects ever used).
  3. In a multithreaded environment, a pool may block the client until another thread returns an object to the pool.


When writing an object pool, the programmer has to be careful to make sure 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, the object will often be in some state that was unexpected by the client program and may cause the client program 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 stale state is not always an issue; it becomes dangerous when the presence of stale state causes the object to behave differently. For example, an object that represents authentication details may break if the "successfully authenticated" flag is not reset before it is passed out, since it will indicate that a user is correctly authenticated (possibly as someone else) when they haven't yet attempted to authenticate. However, it will work just fine if you fail to reset some value only used for debugging, such as the identity of the last authentication server used.

Inadequate resetting of objects may also cause an information leak. If an object contains confidential data (e.g. a user's credit card numbers) that isn't cleared before the object is passed to a new client, a malicious or buggy client may disclose the data to an unauthorized party.

If the pool is used by multiple threads, it may need 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.


Some publications do not recommend using object pooling with certain languages, such as Java, especially for objects that only use memory and hold no external resources [2]. Opponents usually say that object allocation is relatively fast in modern languages with garbage collectors; while the operator "new" needs only 10 instructions, the classic "new" - "delete" pair found in pooling designs requires hundreds of them as it does more complex work. Also, most garbage collectors scan "live" object references, and not the memory that these objects use for their content. This means that any number of "dead" objects without references can be discarded with little cost. In contrast, keeping a large number of "live" but unused objects increases the duration of garbage collection [3]. In some cases, programs that use garbage collection instead of directly managing memory may run faster. [4]


In the .NET Base Class Library there are a few objects that implement this pattern. System.Threading.ThreadPool is configured to have a predefined number of threads to allocate. When the threads are returned, they are available for another computation. Thus, one can use threads without paying the cost of creation and disposal of threads.

Java supports thread pooling via java.util.concurrent.ExecutorService and other related classes. The executor service has a certain number of "basic" threads that are never discarded. If all threads are busy, the service allocates the allowed number of extra threads that are later discarded if not used for the certain expiration time. If no more threads are allowed, the tasks can be placed in the queue. Finally, if this queue may get too long, it can be configured to suspend the requesting thread.

See also


External links

Wikimedia Foundation. 2010.

Игры ⚽ Нужно решить контрольную?

Look at other dictionaries:

  • Object pool — In computer programming, an object pool is a software design pattern. An object pool is a set of initialised objects that are kept ready to use, rather than allocated and destroyed on demand. A client of the pool will request an object from the… …   Wikipedia

  • Pool (computer science) — A pool in computer science is a set of initialised resources that are kept ready to use, rather than allocated and destroyed on demand. A client of the pool will request an object from the pool and perform operations on the returned object. When… …   Wikipedia

  • Pool — may refer to: Bodies of water*Plunge pool, small, deep body of water *The River Pool, river in England, tributary to the River Ravensbourne *Reflecting pool, shallow pool of water designed to reflect a structure and its surroundings: **Capitol… …   Wikipedia

  • Software design pattern — In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a… …   Wikipedia

  • Bloodstain pattern analysis — (BPA) is one of several specialties in the field of forensic science. The use of bloodstains as evidence is not new; however, the application of modern science has brought it to a higher level. New technologies, especially advances in DNA… …   Wikipedia

  • Creational pattern — In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems… …   Wikipedia

  • Multiton pattern — In software engineering, the multiton pattern is a design pattern similar to the singleton, which allows only one instance of a class to be created. The multiton pattern expands on the singleton concept to manage a map of named instances as key… …   Wikipedia

  • Factory method pattern — Factory method in UML Facto …   Wikipedia

  • Concurrency pattern — In software engineering, concurrency patterns are those types of design patterns that deal with multi threaded programming paradigm. Examples of this class of patterns include: Active Object[1][2] Balking pattern Double checked locking pattern… …   Wikipedia

  • Factory object — In object oriented computer programming, a factory object is an object for creating other objects. It is an abstraction of a constructor, and can be used to implement various allocation schemes, such as the singleton pattern.A factory object… …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”