Object pooling
An object pool is a collection of a particular object that an application will create and keep on hand for those situations where creating each instance is expensive. A good example would be a database connection or a worker thread.
Object pooling is designed to even use general purpose objects as well which will be created and destroyed heavily in the application. That’s why during initialization of application objects are generally created which can be set in the method initial pool size.There are config parameters which define the min size, max size and eviction policy of the idle objects from the pool.
Millions of objects can be borrowed but over a period of time and not in one go.You need to size the pool as per the expected number of objects in the peak hour and also assume the amount of time you need to work on that object before returning it.
And If you wish to “hold” millions objects in memory, then it is a caching use case and not a pooling scenario.
Advantage of Object pooling :
Every call to “new” results in a corresponding native call to malloc. That gets avoided in the object pooling. When we have to support high transactions per second, such as 1,000,000 TPS then benefit in latency is precious.
Compare StackObjectPool and SoftReferenceObjectPool
If you use Objects which are having Soft References, then these references are not collected usually until the object is marked for a major collection.Additionally this pool wraps each object in a SoftReference allowing the garbage collector to remove them in response to memory demand
In order to avoid Major GC overhead, we can pool soft reference objects by using this pool. If you do not use soft references, then this pool type is not required.
A simple, Stack-based ObjectPool implementation places no limit on the number of “active” instances created by the pool, but is quite useful for re-using Objects without introducing artificial limits.
Both of them are ObjectPool implementation with a LIFO (Last In First Out) behavior.
Object pool design pattern is explained at following location:
Sample Object pool implementations :
Usually in java, You pool threads by using the in-built JDK thread pools.
Additionally, the classes that implement “Runnable” interface are not only “thread pooled”, but you should also “object pool” them.
This helps in avoiding major object creation and garbage collection overhead for “short lived” thread objects.