Against Object Pools

Do not use object pools in your library

Instead expose an interface for applications to implement their own object pools, such as:

interface Lender<T>
{
    T borrow();
    return(T obj);
}

Why? By definition, an object pool is a leaky abstraction. Quite literally, an object pool holds onto memory once it has allocated it (usually). This means users of your library will need to know about your library's object pools when chasing down a memory leak. However, that is not to say that object pools are bad, they can play a crucial role in reducing allocation times, and help with garbage collection overhead. But whether this optimization is worth the trade-off can only be known at the application level.