This content originally appeared on Level Up Coding - Medium and was authored by Bhargav
Build It, Break It and Fix It!
Singleton pattern is one of the simplest design patterns and falls under creational pattern as this pattern provides one of the best ways to create an object. This pattern involves a single class which is responsible for creating an object while making sure that the instantiation of a class to only one object. This class provides a way to access its only object which can be accessed directly without instantiating the object of the class.
Let’s see various design options for implementing the pattern. If you have a good hold on static class variables and access modifiers this is not a difficult task.
Lazy Instantiation
Here we have declared getInstance() as static so that we can call it without instantiating the class. First time, when getInstance() method is called, it creates a new Singleton object and later it just returns the same object reference. Note that singletonObject is not created until we call the getInstance() method, as we are using the lazy instantiation of the object.
The main problem with the above method is that it is not thread safe. If we have two threads T1 and T2 which invokes the getInstance() method at the same time, the execution sequence creates two objects for Singleton.
The other option is to make getInstance() method as synchronized. Here, using synchronized keyword makes sure that only one thread is allowed at a time to execute getInstance() method. The main disadvantage of this is method is, that using synchronized every time while creating the Singleton object is expensive and may decrease the performance of your program. However if performance of the program. However if performance of getInstance() is not critical for the application this method provides a clean and simple solution.
Eager Instantiation
Here we have created instance of Singleton with the help of static initializer. JVM executes static initializer when the class is loaded and hence this is guaranteed to be thread safe. Use this method only when the Singleton class is light and is used throughout the execution of the program.
Double Check and Locking Instantiation
In the above implementation, we have declared the singletonObject as volatile. Using volatile is yet another way (like synchronized, atomic wrapper) of making class thread safe. Thread safe means that a method or class instance can be used by multiple threads at the same time without any problem. This method drastically reduces the overhead of calling the synchronized method every time.
Now that we know how to implement a Singleton pattern in 3 different ways. Let’s see whether we can break the Singleton pattern ?
Reflection
Reflection is a feature in the Java programming language. It allows an executing Java program to examine or introspect upon itself, and manipulate internal properties of the program. For example, it’s possible for a Java class to obtain the names of all its members and display them.
We will use Reflection and see whether we can break the Singleton or not ?
If you execute the above program, you should see in the output that the hashCode of both objects are different and it clearly violates Singleton pattern.
Singleton.getInstance().hashCode: 1418481495
Reflection.newInstance().hashCode: 303563356
Let’s fix this loop hole by making some simple code change in the Singleton constructor.
private Singleton() {
if (singletonObject != null) {
throw new IllegalStateException("Already Initialised!");
}
}Now if you execute the program with the above changes, the line 24 will call the constructor and it will throw an IllegalStateException. Thus prevents the creation of the second instance.
Caused by: java.lang.IllegalStateException: Already initialised!
What if I change the access level of the singleton field from private to public using the Reflection? Oops… it will allow me to set the singleton object to null and it will create a new object. Let’s modify our main method to hack the Singleton class.
public static void main(String[] args) {
try {
Singleton obj1 = Singleton.getInstance();
System.out.println(
"Singleton.getInstance().hashCode: "
+ obj1.hashCode());
Field field = Singleton.class
.getDeclaredField("singletonObject");
field.setAccessible(true);
field.set(field, null);
Constructor constructor =
Singleton.class.getDeclaredConstructor();
constructor.setAccessible(true);
Singleton obj2 =
(Singleton) constructor.newInstance();
System.out.println(
"Reflection.newInstance().hashCode: "
+ obj2.hashCode());
}
catch (Exception e) {
e.printStackTrace();
}
}Using Reflection, we are changing the value of the instance field to NULL after the object gets created. When we invoke the constructor, the condition fails as singleton instance is null hence it will allow you to create another instance.
We can prevent it by declaring the singletonObject instance as FINAL so that it’s value can’t be changed once assigned.
private final static Singleton singletonObject = new Singleton();
Now if you execute the program, it will throw an IllegalAccessException. Reflection can’t convert final field to non-final field. Please note, this approach only works with Eager Instantiation method.
Serialization
Java provides a mechanism, called object serialization where an object can be represented as a sequence of bytes that includes the object’s data as well as information about the object’s type and the types of data stored in the object.
After a serialized object has been written into a file, it can be read from the file and deserialized, i.e., the type information and bytes that represent the object and its data can be used to recreate the object in memory.
Most impressive is that the entire process is JVM independent, meaning an object can be serialized on one platform and deserialized on an entirely different platform.
We will use Serialization and see whether we can break the Singleton or not ?
If you execute the above program, you should see in the output that the hashCode of both objects are different and it clearly violates Singleton pattern.
Singleton.getInstance().hashCode: 1418481495
Serialization.getInstance().hashCode: 565760380
Let’s fix this loop hole by making some simple code change in the Singleton class. We have to implement readResolve() method and return the singletonObject reference.
protected Object readResolve() {
return singletonObject;
}Conclusion
- We saw how to implement the Singleton Pattern in different ways like Lazy Instantiation, Eager Instantiation and Double Check and Locking Instantiation.
- We saw how we can break the Singleton Pattern using the Reflection and Serialization methods.
- Also, we saw how it can be prevented by making few code changes so the Singleton Pattern won’t allow you to create more than one instance.
References:
Singleton Design Pattern was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Bhargav
Bhargav | Sciencx (2021-05-25T14:54:53+00:00) Singleton Design Pattern. Retrieved from https://www.scien.cx/2021/05/25/singleton-design-pattern/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.