Comments on: Java Singleton

By: chiao

chiao — Mon, 19 Oct 2009 17:47:20 +0000

It will work either way. Any static variables inside the class will be guaranteed to be initialized only once and before they are used. Having other static variables inside the Singleton class does not affect the static “instance” variable inside the inner class. Of course, your variable “example” may not be thread-safe depending on how you use it. But “instance” is still thread safe.

By: David

David — Sat, 17 Oct 2009 23:37:52 +0000

So if you have the same implementation as Initialize-on-demand with the difference being that class Singleton declares a static variable, than this approach wont work and it will not be thread safe ? For example:

public class Singleton{

private static final int example = 0; //static variable declared just for example

private Singleton(){ }

public static Singleton getInstance() {

return SingletonHolder.instance;
}

private static class SingletonHolder {
static final Singleton instance = new Singleton();
}

Thanks for your response.

By: chiao

chiao — Fri, 16 Oct 2009 09:01:30 +0000

Yes, multiple threads can call getInstance() at the same time. But just like Eager Initialization, the thread safety comes from the fact that the singleton instance is ultimately held in a static variable. The JVM guarantees that static variables are only initialized once by the classloader, thus insuring that all threads calling getInstance() will return the same instance of the variable.

The advantage for initialize-on-demand idiom is that the static variable is inside an inner class. The main Singleton class does not contain any static variables so eager instantiation will not take place.

By: David

David — Thu, 15 Oct 2009 19:03:00 +0000

For initialize on demand, isn’t there the possibility that more than one thread may call getInstance() at the same time ?

By: chiao

chiao — Wed, 23 Sep 2009 20:41:16 +0000

Yup, that article talks about the possibility of using reflection to access private constructors in java. By doing so, you can circumvent the private access restriction. So there are ways to break your singleton pattern but if you wanted to break your own code, there are easier ways to do it. The only time this would be a problem in the real world would be a framework or something trying to access your singleton through reflection. That generally will not happen since a singleton by nature would be fairly custom.

I personally have not seen anyone trying to hack their own singletons on purpose. Why go through the trouble of creating a singleton only to hack it into multiple instances? Might as well just create a regular class in the first place.

So that article is not really a contradiction of thread-safe methods for creating singletons. The methods listed here are still thread-safe methods of creating a singleton. But it does not prevent you from using reflection to hack the singleton into multiple instances.