Awesome.....Haven't seen this indepth singleton implementation, mostly people just do a first level of implementation without thinking of the multithreaded environment.
The best channel for design pattern. Loved the explanation. Two more things can be added to this as part of optimization, one Bill Pugh singleton and enum singleton. For Java, the best approach is the Bill Pugh Singleton because it is lazy-initialized, thread-safe, and doesn't require synchronization overhead. public class Singleton { private Singleton() { // Private constructor to prevent instantiation } private static class SingletonHelper { private static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return SingletonHelper.INSTANCE; } } Why is this the best? Lazy Initialization: The instance is created only when getInstance() is called. Thread-Safe: Uses the Java class loader, ensuring thread safety without synchronized. Efficient: No performance overhead of synchronization or volatile variables.
Not sure why you don't have much more views for this video. I don't think anyone explained the multi thread issue in any of the singleton pattern video. Great job and thank you.
Cool video! It would be dope if you could also explain an alternative approach of making a singleton using enums please. Oh, and numbering the videos would be really beginner-friendly and much appreciated by the viewers!
Hi, You explained the singleton pattern very well. However, there is a better way to implement it: using the Bill Pugh Singleton approach. public class Singleton { private Singleton() { // Private constructor prevents instantiation } private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return SingletonHolder.INSTANCE; } } This is thread safe (without using synchronized keyword) + Lazy initialized + easy to implement
I just found out about this channel and subscribed to it. Great Job! Although I think your volatile explanation is a bit wrong. I think volatile tells the OS that this variable will always be written/read to/from the RAM instead of the CPU cache memory. So let's dive in the example where we don't have volatile: Thread A enters the synchronized block and checks if instance is null (still haven't started initialization), at the same time thread B checks if instance is null outside the synchronized block and sees the instance to be null. Therefore thread B also tries to enter the synchronized block but will have to wait for thread A. Thread A after a successful initialization will exit the synchronized block and eventually return. But thread B on the other hand, inside the synchronized block will again see the instance to be null (since the instance variable might only be stored in the cache of a different CPU core where thread A was operating, and where thread B can't see), and will initialize it again. This will not be happening if the "instance" variable is declared volatile: Thread A enters the synchronized block and checks if instance is null (still haven't started initialization), at the same time thread B checks if instance is null outside the synchronized block and sees the instance to be null. Therefore thread B also tries to enter the synchronized block but will have to wait for thread A. Thread A after a successful initialization (will write instance to RAM directly instead of the CPU cache) will exit the synchronized block and eventually return. Now thread B, when checking again if the instance is null inside the synchronized block, will see that it is already initialized (since it will read directly from RAM) and will return that value. Correct me if I am wrong
Thank you for the support! I am afraid you are, it is exactly like I explained in the video, I suggest you watch that part again and if you still have trouble please let me know how can I improve my explanation in the future :) Additionally, feel free to check these references, maybe their approach will be better than mine at explaining the subject: stackoverflow.com/questions/11639746/what-is-the-point-of-making-the-singleton-instance-volatile-while-using-double-l (first answer in this Stack Overflow thread) or en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java (The part where they explain the "Broken multithreaded version"). Hope this helps! Cheers!
So with this pattern you can replace a single simple method that instanciate 10 different classes (implementing the same interface/abstract class) in a switch by 10 new creator classes to respect "Open to extension Close to modification" .... That's AMAZING ... What a great idea that's so much better now. LOL
After instance was initialised, it doesn't matter anymore what String data we pass as parameter to getInstance, it will always return the instance with the data when the method was called the first time. It this really the correct way of doing that?
Very nice! This video was mainly about the Singleton Pattern that is why I didn't want to delve other details. But what you could do is create a map and store several singletons based on their names, then the single instance would be tied to that name. So, in the most common example if you were using the singleton for DB instances and you were using two of them, you'll have two records in your map! Hope this helps :) Cheers!
Good explanation , one question if some one calls clone method on the singleton instance , it will create another object right ? do we have to override clone method and return same instance , please explain ?
6:24 I don't get how volatile fixes the problem. It only makes thread B reread the variable from memory when returning it but the variable could still not be fully initialized by thread A.
If the singleton needs to call a web service to fetch the singleton data such as access token, where do you place the logic to invoke the web service? Do you put it inside the singleton class or outside? Please clarify.
What is the use of "private String data" field here? If i call the getInstance() function with some data string, it will not update the data field of the instance. The first getInstance() call will set the data value and it will never change again. What am I missing?
Nevermind, the question is already asked before and answered well. If anyone thought the same thing: A: Very nice! This video was mainly about the Singleton Pattern that is why I didn't want to delve other details. But what you could do is create a map and store several singletons based on their names, then the single instance would be tied to that name. So, in the most common example if you were using the singleton for DB instances and you were using two of them, you'll have two records in your map! Hope this helps :) Cheers!
No, it's just to check again if an instance is already created while the current thread was waiting for lock to acquire after the first check, 2nd check will be rarely used as most of times first check will be not null and return from there, double check is just for initialisation if many threads are trying to initialise the instance at the same time.
Nope :) This is equivalent to result = new Singleton(data); instance = result; we need to assign the new Singleton created to the instance we have and not just the result being returned or else we will be fetching that result and creating a new instance every time! Cheers!
Very nice job. But we can still break this by serialize the object and deserialize it to create a duplicate object. I guess you should have covered that particular scenario on how to overcome that.
Damn man. That's a unique teaching ability to explain every reason. Nice.
Thanks a lot :) Glad it helped!
My left ear loved this
😂 Check our newest videos, we fixed that!
Incredibly clear man THANKS
Awesome.....Haven't seen this indepth singleton implementation, mostly people just do a first level of implementation without thinking of the multithreaded environment.
The best channel for design pattern. Loved the explanation. Two more things can be added to this as part of optimization, one Bill Pugh singleton and enum singleton.
For Java, the best approach is the Bill Pugh Singleton because it is lazy-initialized, thread-safe, and doesn't require synchronization overhead.
public class Singleton {
private Singleton() {
// Private constructor to prevent instantiation
}
private static class SingletonHelper {
private static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return SingletonHelper.INSTANCE;
}
}
Why is this the best?
Lazy Initialization: The instance is created only when getInstance() is called.
Thread-Safe: Uses the Java class loader, ensuring thread safety without synchronized.
Efficient: No performance overhead of synchronization or volatile variables.
So far the best explanation of Singleton pattern I have come across!!
That was so easy to understand and brilliantly elaborated on!
Very well explained. Please also make a video on singleton patterns using enums. That will be really helpful.
Good channel. I started reading Head First Design Pattern, but I think I'm gonna drop it and just learn from you.
Checking multiple references is not a bad idea, that's what I did when I try to put a video together! I am really glad you found our videos helpful :)
@@geekific Gonna watch them all.
Very well constructed, step by step explanation. Thank you!
Very nicely explained. Thanks!
Great explaining skills, I read many documentation but I completely understood from your video
Awesome, thank you! Glad it was helpful :)
Thanks for the video, it was really useful.
Not sure why you don't have much more views for this video. I don't think anyone explained the multi thread issue in any of the singleton pattern video. Great job and thank you.
The only thing I have to say is 'Perfectly Awesome..........'. Thank you!
Cool video! It would be dope if you could also explain an alternative approach of making a singleton using enums please. Oh, and numbering the videos would be really beginner-friendly and much appreciated by the viewers!
Will add it to my list of upcoming videos! Stay Tuned!
Hey man, your videos are super awesome. Thank you so much for the good work
Thank you so much for a well coordinated video!! Kudos to you
My pleasure :) Glad you liked it!
Thank you so much for making this video. Helped a lot!
Thanks for clear explanation!
Hi, You explained the singleton pattern very well. However, there is a better way to implement it: using the Bill Pugh Singleton approach.
public class Singleton {
private Singleton() {
// Private constructor prevents instantiation
}
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
This is thread safe (without using synchronized keyword) + Lazy initialized + easy to implement
Your videos are so so so good!! Thank You!!
That was giga clear.
Tanks buddy
Well explained
I just found out about this channel and subscribed to it. Great Job!
Although I think your volatile explanation is a bit wrong.
I think volatile tells the OS that this variable will always be written/read to/from the RAM instead of the CPU cache memory.
So let's dive in the example where we don't have volatile:
Thread A enters the synchronized block and checks if instance is null (still haven't started initialization), at the same time thread B checks if instance is null outside the synchronized block and sees the instance to be null. Therefore thread B also tries to enter the synchronized block but will have to wait for thread A. Thread A after a successful initialization will exit the synchronized block and eventually return. But thread B on the other hand, inside the synchronized block will again see the instance to be null (since the instance variable might only be stored in the cache of a different CPU core where thread A was operating, and where thread B can't see), and will initialize it again.
This will not be happening if the "instance" variable is declared volatile:
Thread A enters the synchronized block and checks if instance is null (still haven't started initialization), at the same time thread B checks if instance is null outside the synchronized block and sees the instance to be null. Therefore thread B also tries to enter the synchronized block but will have to wait for thread A. Thread A after a successful initialization (will write instance to RAM directly instead of the CPU cache) will exit the synchronized block and eventually return. Now thread B, when checking again if the instance is null inside the synchronized block, will see that it is already initialized (since it will read directly from RAM) and will return that value.
Correct me if I am wrong
Thank you for the support! I am afraid you are, it is exactly like I explained in the video, I suggest you watch that part again and if you still have trouble please let me know how can I improve my explanation in the future :) Additionally, feel free to check these references, maybe their approach will be better than mine at explaining the subject: stackoverflow.com/questions/11639746/what-is-the-point-of-making-the-singleton-instance-volatile-while-using-double-l (first answer in this Stack Overflow thread) or en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java (The part where they explain the "Broken multithreaded version"). Hope this helps! Cheers!
Nicely explained. Thank you!
Super clear 👏 Thank you !
overwhelmed
So with this pattern you can replace a single simple method that instanciate 10 different classes (implementing the same interface/abstract class) in a switch by 10 new creator classes to respect "Open to extension Close to modification" .... That's AMAZING ... What a great idea that's so much better now. LOL
the best i've seen
sick explanation and video
Thanks! Glad you liked it :)
You are amazing bro, you nailed it, I will definitely subscribe to such an amazing and valuable content channel, wish you growth and wealth :)
I appreciate that! Thanks for the support :)
That was a great explanation
thank you so much ,very clear
Absolutely love the video although the last third of the video took 90% of my brainpower to keep up
Great video. But how to we actually use it now? Should there also be a setter to update the variables?
Thank you!
Excellent
After instance was initialised, it doesn't matter anymore what String data we pass as parameter to getInstance, it will always return the instance with the data when the method was called the first time. It this really the correct way of doing that?
Very nice! This video was mainly about the Singleton Pattern that is why I didn't want to delve other details. But what you could do is create a map and store several singletons based on their names, then the single instance would be tied to that name. So, in the most common example if you were using the singleton for DB instances and you were using two of them, you'll have two records in your map! Hope this helps :) Cheers!
That's exactly what I thought.
Good channel. Helped me a lot. However I would request you to put even more detail to compete with other channels.
Happy it helped! and thanks for the feedback will take it into consideration in future videos :)
Good explanation , one question if some one calls clone method on the singleton instance , it will create another object right ? do we have to override clone method and return same instance , please explain ?
6:24 I don't get how volatile fixes the problem. It only makes thread B reread the variable from memory when returning it but the variable could still not be fully initialized by thread A.
It won't be there!
@@geekific I am afraid I don't understand what you are referring to, what won't be where?
It will not be written to memory until fully initialized
OMG wow man
amazing!
Thank you :)
Why not use a local variable to construct an object and assign it to the static variable later.
This way you can avoid using volatile
please explain eager and lazy instantion
If the singleton needs to call a web service to fetch the singleton data such as access token, where do you place the logic to invoke the web service? Do you put it inside the singleton class or outside? Please clarify.
Depends on what your singleton is. If that's its whole purpose, like a token generator or something then it should go inside.
What's the music in the beginning?
What is the use of "private String data" field here? If i call the getInstance() function with some data string, it will not update the data field of the instance. The first getInstance() call will set the data value and it will never change again. What am I missing?
Nevermind, the question is already asked before and answered well. If anyone thought the same thing:
A: Very nice! This video was mainly about the Singleton Pattern that is why I didn't want to delve other details. But what you could do is create a map and store several singletons based on their names, then the single instance would be tied to that name. So, in the most common example if you were using the singleton for DB instances and you were using two of them, you'll have two records in your map! Hope this helps :) Cheers!
Good explanation, but the second if condition is redundant, isn't it?
Thank you! Basically more than half of the video was dedicated into answering this question. Kindly watch between 3:25 to 7:00. Cheers!
No, it's just to check again if an instance is already created while the current thread was waiting for lock to acquire after the first check, 2nd check will be rarely used as most of times first check will be not null and return from there, double check is just for initialisation if many threads are trying to initialise the instance at the same time.
I think there is one mistake. An additional 'instance =' At the end it says instance = result = new Singleton(data);
Nope :) This is equivalent to result = new Singleton(data); instance = result; we need to assign the new Singleton created to the instance we have and not just the result being returned or else we will be fetching that result and creating a new instance every time! Cheers!
Oh, good to know. Thanks
i want a written notes of what ever he said
can someone help me?
good
Very nice job. But we can still break this by serialize the object and deserialize it to create a duplicate object. I guess you should have covered that particular scenario on how to overcome that.
Thanks for the feedback! Will keep that in mind for future videos! Stay Tuned :)
There is so much stuff there. This feels like it should be solved by just making the whole thing a global atribute.
"most used pattern"
- As far as I know, many programmers call it an anti-pattern...
Being an anti-pattern isn't keeping people from using it ;P
It's called global variables.
Cool, but you should use enum for that.
kichui bujhlam na
Please, let us know which parts exactly were not clear so we may try and help in the comments section :)
That was giga clear.
Tanks buddy