Does object pool pattern requires creation of objects before they even needed

Question

If I use object pool design pattern, do I have to create the objects before that anyone needs them, or that I can create every object only when someone needs it, and then (after he used it), put it in the pool? Thus, to start with an empty pool, and fill it over time, and create objects only when someone needs to use them, and they are not currently in the pool?

Answer 1

From wiki:

The object pool pattern is a software creational design pattern that uses a set of initialized objects kept ready to use – a "pool" – rather than allocating and destroying them on demand.

Thus, the main idea of this pattern is to pre-create an object pool in situations where the cost of creating and initializing a class instance is high and in other situations where instantiating an object on demand would be less efficient.

Answer 2

Both approaches are valid implementations of the design pattern. You may choose to fill the pool up front or as needed, depending on requirements.

A common use case for object pooling is threads. In Java we can see the two approaches implemented in Cached ThreadPool vs Fixed ThreadPool. The cached version creates threads on demand; the fixed version creates threads in advance.

Answer 3

The main goal of the Object Pool pattern is to minimize the performance costs of expensive instances. Expensive could mean: uses/blocks valuable resources or is time consuming to instantiate/configure/initialize. By reusing instances you avoid excessive instantiation and are able to manage limited resources.

The most famous example is the thread pool. It is used by many languages to improve threading performance. Although threads are used to increase performance by parallelizing operations or tasks, threads themselves are very expensive to create. Threads are managed on OS level. Extra memory must be allocated and the executing code and all referenced resources must be copied. New thread context like call stacks must be created and instruction pointers initialized...
It is significantly cheaper to reuse a previously used thread.

This costs are also the reason why you won't blindly fill up the pool in advance. In case you don't know if any object in the pool is finally used, you would create the objects on-demand. If you know that the pooled objects are very likely to be used you can initialize the pool with objects. According to the context you either fill up the pool to its capacity or just to a certain object count and generate more on-demand.

Efficient pool implementations have a minimum and maximum limit and are implemented as a queue of pooled objects. Depending on the context you may also add a second queue to enqueue tasks or requests in case all pooled objects are in use. There are different algorithms to handle requests for resources e.g. using priority queues or round-robin.

Since you want to prevent the clients of the pool from starving and the main goal to use a pool is to improve performance using smart object instance management, the Object Pool pattern only makes sense in scenarios where the instances are used for a short time. Otherwise it could be better to create instances directly (if resources are not limited).