A potential problem of this approach is that the ClassLoader is allowed to unload the class if there are no refferences to it, and reload it the next time it's used. This leads to problems if your singleton has state. E.g. a singleton registry class could just 'forget' everything. What's worse - this probles happen only once in a while - it depends on the memory available, usage pattern and the concrete JVM implementation.
regards, Dimiter Gordon Tyler wrote: > > > Christopher Cobb wrote: > >> Unfortunately, these approaches do not address multithreading or >> serialization issues. >> >> See 'Effective Java' by Joshua Bloch, or >> http://www.javaworld.com/javaworld/javaqa/2002-04/01-qa-0412-doublelock.html. >> > > > For our project, we use the following pattern for our singletons which > avoids the double-locking problem: > > public class Foo { > private static class SingletonInstance { > private static final Foo instance = new Foo(); > } > > public static Foo getInstance() { > return SingletonInstance.instance; > } > } > > Class loading and field initialisation semantics guarantee that the > instance will be created before any thread accesses the field via > Foo.getInstance(). > > Ciao, > Gordon > _______________________________________________ Eap-features mailing list [EMAIL PROTECTED] http://lists.jetbrains.com/mailman/listinfo/eap-features
