Difficult to tell without code tags, and just doing it from memory, but I think "B".
You ought to synchronize the getInstance method, otherwise two threads accessing it simultaneously can get different instance. There is a long discussion in Shalloway and Trott which is reviewed in the BunkHouse Books section about the Singleton, and they say you have to take special precautions about synchronizing a Singleton in Java, but I can't remember the full details.
There is no such thing as a singleton. There is only such thing as a "singleton" within a defined context. Many Java developers erroneously believe that a class loader encapsulates the entire universe(s?). Once you define the context (typically a class loader), then and only then can you talk about a singleton. One might shift the context around - greater or lesser - and talk about the notion of a "singleton".
For example, a local declaration is a singleton within its scope. Likewise, an instance shared among many class loaders in different VMs in different positions in spacetime may be referred to as a singleton (within the context of those VMs). You can shift the boundaries around whichever way you like - the arbitrarily chosen "class loader" to somehow mean "everything there ever was" is based on some misconceptions (which are based on even more misconceptions, etc.) posed by demigods (read: book authors) many years ago.
I prefer the first style. There is a caveat that it creates an instance the first time the class is referenced, whether you really meant to get a instance or not, but this has never (yet) been an important thing to me.
is not thread safe. That means two threads calling this code at the same time might get two different instances, which is not what you want. Attempts to make it thread safe with synchronized blocks are common in older references - even Sun's - but they flat don't work. Synchronize the whole method to make it safe.
Tony's point, boiled down, is that you can't reliably force one instance per JVM with this code. Instead you'll get one instance per ClassLoader. Simple standalone apps work fine with a single ClassLoader for all the application code, but many frameworks and containers like Servlet and EJB containers have complex families of ClassLoaders. If it's mission critical to really have only one instance in those environments, things get pretty tricky.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Apr 16, 2005
so u mean in servlets and ejb's the containers use their own classloader for laoding the lcassses at runtime.. what ever... the class loader must create only one instance as we are also keeping synchrinized modifier to getInstance method
so it must surely create only one object
am i right ? :roll:
Joined: Apr 16, 2005
actuall the first code clearly copies the Runtime class because Runtime class has got private constructor and also it allows the user to create an instance uysing the static method i dont know why Runtime class doesn't allow the user to create an object directly..
I said that a bit to strongly ... you might get one per class loader. It's not that every class loader will automatically make a new one, but it could.
Applications can use new ClassLoaders as well as frameworks and containers, most commonly to alter the classpath or dynamically reload classes I'd guess. So if you have two instances of Test during the day you have little assurance that they were loaded by the same ClassLoader and they could get two different instances of Run.
Originally posted by Stan James: I prefer the first style. There is a caveat that it creates an instance the first time the class is referenced, whether you really meant to get a instance or not, but this has never (yet) been an important thing to me.
This seems to be a common misconception. The truth is the variable initializers and static initializer are executed when the class is initialized. A class is not necessarily initialized when it is loaded and can even be 'referenced' (depending on what you mean by that) if, for example, it was a constant variable of the class that was used.