Object Pooling Can Be Still Useful - For Entirely Different Reasons
Pooling was initially introduced as a tuning action for the slow performance of object creation and garbage collection in particular. On a modern JVM > 1.4 pooling is no more needed for the optimization of memory management in a typical business application. It can even have a negative effect on the garbage collector performance. In special cases, like creating millions of instances in every method call, it could still pay off.
Instance pooling, however is still interesting for objects with slow custom "post construction". In some cases you want to inject some dependencies after the object creation, read some configuration etc. This can be slow and doesn't have to be performed over and over again. In such cases object pooling will improve the overall performance.
Instead of prematurely optimize your application, I would rather build the simplest possible thing and measure the performance continuously (e.g. with VisualVM). In most cases you will be surprised where the actual bottlenecks actually are.
This assumes that you have to create new instances all the time - a Singleton based solution like Spring does not need this as only one instance will be created anyway.
Posted by Eberhard Wolff on February 02, 2010 at 11:36 AM CET #
@Eberhard Wolff This does not work well in situations where the state of the instance should be saved.
Posted by Mateus Bicalho on February 02, 2010 at 03:08 PM CET #