Although he is one of the most controversial Design Patterns, I found it REALLY FUN to explore this issue what lead me to apply 9 different ways to implement this pattern. Credit goes to my AWESOME lecturer Kobi Shasha, from whom I draw a lot of inspiration. Let's Begin!
Compared to Eager Singleton, instead of generating a "new object" in the field, we will
initialize the field value to null.
This way, "new object" will be created only by demand.
The instance will be created within the "getter" method
only once, at the first time an external entity outside of this specific class requires it.
In order to avoid situations when multiple threads in a single program try to access the same
resource at the same time we can use synchronized static method.
This approach isn't the best practice since the
performance of the system can degrade due to the
slow working of the synchronized keyword.
In attempt to make the previous implementation efficient, we will add a synchronized block
inside the getter method, i.e. only in the critical section - where the "new" object is
created.
Which supposedly improves the performance because the
synchronization is only on the critical part, but this Singleton isn't thread safe and known as
The Double Lock Problem.
To solve the double lock problem we encountered in the previous implementation, and to ensure our
Singleton is a thread safe, we will perform another check to make sure the instance is null -
inside the block we created.
This way we will get a Singleton which is both, more
efficient and a thread safe.
Another way to implement Multithreaded Singleton, is by using Volatile modifier that provides a
way to control memory order.
By using Volatile, we ensure a couple of rules for consistent behavior:
Mutual Exclusion – only one thread executes a critical
section at a time.
Visibility – changes made by one thread to the shared
data are visible to other threads to
maintain data consistency.
The fact that the field is "static" and initialized as a "new object" means that he will be
loaded in the very first steps of the program loading - what makes him eager.
Constructor must be private.
Getter must be public because that's the only way to
get the instance outside of that particular
class.
The JVM defers initializing the MySingleton class until it is actually used, and because the Singleton is initialized with a static initializer, no additional synchronization is needed.
View source code on githubSince enums are inherently serializable, we don't need to implement it with a serializable interface. Therefore, it is 100% guaranteed that only one instance of the singleton is present within a JVM.
View source code on githubIn Spring, we can create singleton by making use of Spring's singleton beans or by implementing
the singleton design pattern ourselves.
Just use Spring Framework project, by default, all
Spring beans are Singletons.
In the terms of which type of loading works best, it all depends on your individual needs.
See what former colleagues think about me
I worked with Chelly in order to promote collaborations for she codes;. She is a hard worker and very dedicated. I believe that she will be a huge asset for any organization.
Chelly is an enthusiatic team member who contributes excellent content to our branch meetings. It is a pleasure to have her with us and she will be an asset wherever she goes.
Chelly's lecture was delivered brilliantly. It helped kindle a renewed enthusiasm for our team goals.
Chelly gave a tech lecture at Soluto branch which I manage. She naturally kept the audience of about 30 members active and attentive, while explaining the material clearly and thoroughly. Chelly is easy to communicate with, knowledgeable and serious. It was great having her as a lecturer.
I'd love to hear from you!