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. 


NEW: Online Workhop Effective WebApps without Frameworks is also coming to: MUC Airport.

Airport MUC workshops: Web (SPA, PWAs, Offline, Desktop, Mobile) Applications Essentials and Effective Web Applications. No migrations. #usetheplatform

Podcast: airhacks.fm and newsletter: airhacks.news

A book about rethinking Java EE Patterns

Comments:

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 #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
realworldpatterns.com
...the last 150 posts
...the last 10 comments
License