In this post I am going to explain some additional restrictions on this pattern

1) Lazy initialization with double lock mechanism

2) Early initialization

3) Serialization

4) ClassLoaders

5) Restrict Cloning

Lazy instantiation using double locking mechanism

The standard implementation shown in the code above is a thread safe implementation, but it’s not the best thread-safe implementation because synchronization is very expensive when we are talking about the performance. We can see that the synchronized method getInstance does not need to be checked for synchronization after the object is initialized. If we see that the singleton object is already created we just have to return it without using any synchronized block. This optimization consist in checking in an un-synchronized block if the object is null and if not to check again and create it in an synchronized block. This is called double locking mechanism.

In this case case the singleton instance is created when the getInstance() method is called for the first time. This is called lazy instantiation and it ensures that the singleton instance is created only when it is needed.

In the following implementattion the singleton object is instantiated when the class is loaded and not when it is first used, due to the fact that the m_instance member is declared static. This is why in this implementation we don’t need to syncronize any portion of the code. The class is loaded once this guarantee the unicity of the object

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented. See Serializable () and readResolve Method () in javadocs.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

ClassLoaders

If you have multiple classloaders(possibilities in case of servlet container) then the patterns will allow for multiple instances to be created which is not expected
To overcome this you have to have the custom implementation like

If we try to access the above singleton object using reflection then you will get

Exception in thread "Main Thread" java.lang.IllegalAccessException: Class com.example.thread.Main can not access a member of class com.simple.NormalClass with modifiers "private"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
at java.lang.Class.newInstance0(Class.java:349)
at java.lang.Class.newInstance(Class.java:308)
at com.example.thread.Main.main(Main.java:10)

if you are using java 1.5 and above you can use enum type which takes care of all the above

the servlet includes servlet lifecycle methods to initialize and process the request

init(ServletConfig) – FacesContextFactory,LifeCycleFactory is identified and the lifeCycle reference is obtained with the default lifecycle idservice() – the pathInfo is manipulated from WEB-INF and META-INF folder from the request, FacesContext is obtained, lifecycle is executed and rendered, later the context is releaseddestroy() – all the instances are destroyed.. technically speaking nullified