Java Singleton vs static - is there a real performance benefit?

Question

I am merging a CVS branch and one of the larger changes is the replacement wherever it occurs of a Singleton pattern with abstract classes that have a static initialisation block and all static methods.

Is this something that's worth keeping since it will require merging a lot of conflicts, what sort of situation would I be looking at for this refactoring to be worthwhile?

We are running this app under Weblogic 8.1 (so JDK 1.4.2)

cheers Matt

Answer 1

I just want to make sure I'm reading this correctly. One version has a Singleton class. The other version replaced that Singleton class with a static class. Is that correct?

Answer 2

Does this discussion help? (I don't know if it's taboo to link to another programming forum, but I'd rather not just quote the whole discussion =) )

Sun Discussion on this subject

The verdict seems to be that it doesn't make enough of a difference to matter in most cases, though technically the static methods are more efficient.

Answer 3

From a strict runtime performance point of view, the difference is really negligible. The main difference between the two lies down in the fact that the "static" lifecycle is linked to the classloader, whereas for the singleton it's a regular instance lifecycle. Usually it's better to stay away from the ClassLoader business, you avoid some tricky problems, especially when you try to reload the web application.

Answer 4

If my original post was the correct understanding and the discussion from Sun that was linked to is accurate (which I think it might be), then I think you have to make a trade off between clarity and performance.

Ask yourself these questions:

1. Does the Singleton object make what I'm doing more clear?
2. Do I need an object to do this task or is it more suited to static methods?
3. Do I need the performance that I can gain by not using a Singleton?

Answer 5

sorry Thomas, let me clarify..

the HEAD version has the traditional singleton pattern (private constructor, getInstance() etc)

the branch version has no constructor, is a 'public abstract class' and modified all the methods on the object to be 'static'. The code that used to exist in the private constructor is moved into a static block.

Then all usages of the class are changed which causes multiple conflicts in the merge.

There are a few cases where this change was made.

thanks Matt

Answer 6

I would use a singleton if it needed to store any state, and static classes otherwise. There's no point in instantiating something, even a single instance, unless it needs to store something.

Answer 7

From my experience, the only thing that matters is which one is easier to mock in unit tests. I always felt Singleton is easier and natural to mock out. If your organization lets you use JMockit, it doesn't matter since you can overcome these concerns.

Answer 8

Static is bad for extensibility since static methods and fields cannot be extended or overridden by subclasses.

It's also bad for unit tests. Within a unit test you cannot keep the side effects of different tests from spilling over since you cannot control the classloader. Static fields initialized in one unit test will be visible in another, or worse, running tests concurrently will yield unpredictable results.

Singleton is generally an ok pattern when used sparingly. I prefer to use a DI framework and let that manage my instances for me (possibly within different scopes, as in Guice).

Answer 9

Write some code to measure the performance. The answer is going to be dependent on the JVM(Sun's JDK might perform differently than JRockit) and the VM flags your application uses.