Object Pool Pattern, also know as Resource Pool Pattern, is a creational Design Pattern.

Software applications often face the challenge of excessive overhead and performance degradation caused by repetitive object creation and destruction. This issue is particularly pronounced when resource-intensive or costly operations are involved. The conventional approach of creating new objects as needed leads to decreased efficiency and increased latency.

To address this problem, it is crucial to optimize resource management and enhance performance by minimizing unnecessary object creation and destruction. A solution should enable the reuse of initialized and valid objects, thereby reducing the associated overhead and improving the overall responsiveness and scalability of the application.

Intent of Object Pool Pattern

The object pool pattern aims to optimize resource management and enhance performance by reusing objects rather than continually creating and destroying them. By maintaining a pool of pre-initialized objects, the pattern effectively reduces the overhead typically associated with object creation, particularly in situations where the creation process is costly or time-consuming. This pattern offers an efficient approach to manage and distribute resources, ultimately improving scalability and responsiveness within software applications.

Real World Analogy

Let’s dive into a real-world analogy that can shed light on the object pool pattern: a car rental agency.

Imagine yourself as the owner of a car rental business with a limited number of cars at your disposal. Instead of buying and selling cars every time a customer needs one, you decide to implement an object pool approach.

In this context, the pool symbolizes your fleet of cars. Initially, you create a pool of fully prepared and available rental cars. When a customer comes in to rent a car, instead of purchasing a new car or waiting for one to be manufactured, you check the pool for an available car. Should one be available, you promptly provide it to the customer.

After the customer returns the car, you don’t immediately sell or dispose of it. Instead, you return the car back to the pool, making it available for the next customer. This way, you can maximize the utilization of your existing cars and minimize the time and resources spent on purchasing or manufacturing new ones.

By employing the object pool pattern within this analogy, you effectively administer your car resources, sidestepping the associated burdens of continuous car creation and disposal. Through the reuse of cars from the pool, you streamline the rental process, enrich customer service, and ensure superior resource allocation in your car rental enterprise.

Implementation

Components of Object Pool Pattern

The object pool pattern typically consists of the following components:

1. Object Pool: This is the central component of the pattern. It represents the pool or collection of reusable objects. The object pool is responsible for managing the lifecycle of objects, controlling their creation, allocation, and deallocation.
2. Object Creation: The object pool pattern includes a mechanism for creating and initializing a fixed number of objects in the pool during its initialization phase. This ensures that the pool has a sufficient number of objects readily available for use.
3. Object Reuse: When an object is requested from the pool, the object pool determines if there are any available (unused) objects. If an object is available, it is provided to the requester. The object’s state may be reset if necessary to ensure it’s in a clean and valid state for reuse.
4. Object Pooling Strategy: The object pool pattern may incorporate a strategy for managing object availability and object exhaustion scenarios. It defines how the object pool handles situations when all objects are currently in use, such as blocking until an object becomes available, creating a new object on demand, or throwing an exception.
5. Object Return: After an object is no longer needed by the requester, it is returned to the object pool instead of being destroyed. The object pool marks the object as available for reuse, making it accessible to other parts of the application that may need it.
6. Object Validation (optional): In some implementations, the object pool pattern may include a mechanism to validate objects before they are returned from the pool. This validation ensures that objects are still in a valid state and fit for reuse.

Components in our Car rental service

Here’s how the analogy relates to the object pool pattern:

1. Initialization: At the start of the day, you have a fixed number of cars available in your rental fleet. These cars are ready to be rented by customers and are in a valid state (cleaned, fueled, and properly maintained).
2. Car Request: When a customer comes to your rental counter and requests a car, you check if there are any available cars in your pool.
3. Car Reuse: If a car is available, you provide it to the customer. The car is then marked as “rented,” and its details are recorded for the rental period.
4. Car Exhaustion: If all the cars in the pool are rented out, you may either ask the customer to wait until a car becomes available (blocking) or inform them that no cars are currently available (exception).
5. Car Return: When a customer returns a rented car, instead of selling or scrapping it, you return it to the car pool. The car is then made available for future customers to rent.
6. Car Validation (optional): As an optional component, the car rental service may implement car validation before reassigning a returned car to a new customer. This validation process ensures that the car is still in good condition, thoroughly cleaned, and meets safety standards.

Java Example

Generic Object Pool

package com.neatcode.designpattern.objectpool;

import java.util.HashSet;
import java.util.Optional;
import java.util.Set;

/**
 * Generic object pool.
 *
 * @param <T> Type T of Object in the Pool
 */
public abstract class ObjectPool<T> {

    private final Set<T> available = new HashSet<>();
    private final Set<T> inUse = new HashSet<>();

    private int currentInventorySize;

    protected abstract Optional<T> create();

    /**
     * Checkout object from pool.
     */
    public synchronized T request() {
        if (available.isEmpty()) {
            Optional<T> obj = create();
            if(obj.isPresent()) {
                available.add(obj.get());
                currentInventorySize += 1;
            }
        }
        var instance = available.iterator().next();
        available.remove(instance);
        inUse.add(instance);
        return instance;
    }

    public synchronized void release(T instance) {
        inUse.remove(instance);
        available.add(instance);
    }

    public int getInventorySize() {
        return this.currentInventorySize;
    }

    @Override
    public synchronized String toString() {
        return String.format("Pool available=%d inUse=%d", available.size(), inUse.size());
    }
}

Car.java

package com.neatcode.designpattern.objectpool;

public class Car {
    private String licensePlate;
    private boolean available;

    public Car(String licensePlate) {
        this.licensePlate = licensePlate;
        this.available = true;
    }

    public String getLicensePlate() {
        return licensePlate;
    }

    public boolean isAvailable() {
        return available;
    }

    public void setAvailable(boolean available) {
        this.available = available;
    }
}

CarRentalService.java – uses object pool of Cars

package com.neatcode.designpattern.objectpool;

import java.util.Optional;

public class CarRentalService extends ObjectPool<Car> {
    private int maxCars;

    public CarRentalService(int maxCars) {
        this.maxCars = maxCars;
    }

    @Override
    protected Optional<Car> create() {
        if (this.getInventorySize() < maxCars) {
            String randomLicensePlate = "IN 01 AA " + getInventorySize() + 1;
            Car newCar = new Car(randomLicensePlate);
            return Optional.ofNullable(newCar);
        };
        return Optional.empty();
    }
}

Main.java

package com.neatcode.designpattern.objectpool;

public class App {
    public static void main(String[] args) {
        var pool = new CarRentalService(3);
        System.out.println(pool);
        Car car1 = pool.request();
        System.out.println("Requested a car");
        System.out.println(pool);
        Car car2 = pool.request();
        System.out.println("Requested a car");
        System.out.println(pool);
        Car car3 = pool.request();
        System.out.println("Requested a car");
        System.out.println(pool);
        pool.release(car1);
        System.out.println("Released a car");
        System.out.println(pool);
        pool.release(car2);
        System.out.println("Released a car");
        System.out.println(pool);
        Car car4 = pool.request();
        System.out.println("Requested a car");
        System.out.println(pool);
        Car car5 = pool.request();
        System.out.println("Requested a car");
        System.out.println(pool);
    }
}

Best Practices & Key Considerations

Here are some best practices and key considerations to keep in mind when implementing the object pool pattern:

1. Carefully Determine Object Pool Size: The size of the object pool should be determined based on the anticipated demand and available system resources. It should strike a balance between providing enough objects to meet the demand without causing resource contention or excessive resource allocation.
2. Thread Safety and Concurrency: If the object pool is accessed by multiple threads concurrently, it is essential to ensure thread safety. Proper synchronization mechanisms, such as locks or concurrent data structures, should be used to prevent race conditions and ensure consistent behavior.
3. Object Lifecycle Management: Pay close attention to the lifecycle of objects within the pool. Objects should be properly initialized before adding them to the pool, and any necessary cleanup or resetting should be performed when objects are returned to the pool. This ensures that objects are in a consistent and reusable state.
4. Object Validation and Rejuvenation: Implement mechanisms to validate the state and integrity of objects when they are acquired from the pool. This helps to identify and handle any potential issues with objects. Additionally, consider implementing object rejuvenation mechanisms to refresh or reset objects in the pool periodically to avoid staleness or resource leaks.
5. Pool Size Management: Consider dynamically adjusting the pool size based on demand patterns. Monitoring the usage and performance of the pool can help identify situations where the pool size needs to be increased or decreased to optimize resource utilization.
6. Proper Error Handling: Handle exceptions and errors gracefully within the object pool implementation. Make sure to release resources, remove any problematic objects from the pool, and provide appropriate feedback or notifications to the calling code.
7. Object Pool Configuration: Provide flexibility in configuring the object pool, such as allowing customization of pool size, timeout periods for acquiring objects, and other relevant parameters. This allows the object pool to be tailored to specific application requirements.
8. Properly Dispose of Unused Objects: If objects within the pool hold external resources (e.g., database connections), ensure that unused objects are properly disposed of or released to free up the associated resources. This helps avoid resource leaks and ensures efficient resource utilization.
9. Testing and Performance Tuning: Thoroughly test the object pool implementation, including scenarios with high concurrency and stress testing. Monitor the performance and resource usage of the object pool under different workloads and tune the implementation as needed to achieve optimal performance.

Real World Applications of Object Pool

The object pool pattern has numerous real-world applications, enabling efficient resource management and improved performance. Transitioning to a more user-friendly style, let’s explore some notable use cases where the object pool pattern proves valuable:

1. Database Connection Pooling: In applications driven by databases, establishing and closing connections can be resource-intensive and time-consuming. However, by utilizing the object pool pattern, a pool of pre-initialized database connections is maintained. This allows for efficient connection reuse and minimizes the overhead associated with establishing new connections.
2. Thread Pooling: In multi-threaded applications, the creation and destruction of threads can be costly. To address this, the object pool pattern can be employed to manage a pool of pre-created and idle threads. When a task needs execution, a thread is allocated from the pool. After completing the task, it is returned to the pool for subsequent reuse. This eliminates the overhead of frequent thread creation and termination.
3. Resource Pooling: The object pool pattern finds practical use in scenarios where resources are limited or expensive to create. For instance, managing connections to external systems (e.g., API connections), file or network socket handles, or computationally intensive resources. By pooling and reusing these resources, the object pool pattern optimizes resource utilization and enhances overall performance.
4. Object Reuse in Game Development: In game development, objects such as bullets, enemies, or particle effects often necessitate frequent creation and destruction. However, the object pool pattern can be employed to reuse these objects instead. By doing so, it mitigates the need for continuous creation and destruction, resulting in improved performance due to reduced memory allocations and garbage collection overhead.
5. Web Server Request Handling: Web servers often encounter the challenge of handling concurrent client requests. Through the object pool pattern, reusable request handler objects can be efficiently managed. This allows the server to allocate and deallocate handlers as needed, eliminating the need for creating and destroying them for each request. Consequently, this improves performance by reducing resource overhead.

Pros & Cons of Object Pool Pattern

Relation with other Patterns

The object pool pattern has a close relationship with several other design patterns that can be combined to address specific software development needs. Let’s explore these patterns using easy-to-understand language and transition words:

1. Factory Pattern: The factory pattern works well with the object pool pattern. It helps create and initialize objects in the pool by encapsulating the object creation logic. The factory pattern takes care of creating and configuring the objects added to the pool.
2. Singleton Pattern: By implementing the object pool pattern using the singleton pattern, the pool becomes a singleton object responsible for managing the pool of reusable objects. This ensures that there is only one instance of the object pool throughout the application.
3. Proxy Pattern: In the object pool, the proxy pattern can be used to add extra functionalities or control over the objects. Proxy objects act as wrappers around the pooled objects, allowing for additional checks, logging, or security measures.
4. Decorator Pattern: With the decorator pattern, you can dynamically modify the behavior of objects retrieved from the object pool. By using decorators, you can extend the functionality of the pooled objects without altering their underlying implementation.
5. Observer Pattern: When multiple components or modules in the system need to know the availability of objects in the pool, the observer pattern comes in handy. Observers can subscribe to notifications from the pool, receiving updates when objects become available or are returned to the pool.
6. Flyweight Pattern: The object pool pattern shares similarities with the flyweight pattern. Both patterns focus on efficient resource utilization. The flyweight pattern minimizes memory usage by sharing common state among multiple objects, while the object pool pattern reuses entire objects to reduce the overhead of object creation.

Wiki: https://en.wikipedia.org/wiki/Object_pool_pattern