one remark: regarding your first implementation of the singleton in a double checked manner, you can't use "this" in a static context. synchronize(this) is not permitted, but synchronize(Resource.Class) is working fine.
Caution: These 3 patterns are for lazy loading an object. It should be used only when object is very expensive to create and it may or may not be actually called during lifetime of the application. In practical scenarios we rarely need lazy load. It can impact performance when first time the method is called. Instead just eagerly create the singleton. In this case application will take some time to start, but the users/threads will not have any impact when calling the method once application is up.
Hi Defog Tech. I cannot express how grateful I'm for the videos you made on your channel. They are all simple, elegant, and straight to the point. I would like to see a video where you suggest a list of books that are on your bookshelf or that you're going to read. Thanks!
@@trinhduyhung8211 Thanks a lot for the kind words! I generally read articles, CS papers and such since information is very scattered. But will share whichever books I have found useful.
@@rzahir7392 Volatile keyword tells the compiler not to do any reordering because the variable is shared between threads. So along with flushing to memory on every write (happens before) volatile also stops reordering of instructions involving the volatile variable.
Excellent video! I was looking for an explanation for the 'Double Checked Locking' and they were all very confusing or did not explain some things but your video explained it very well. also I learned other things like the 'volatile' keyword Thank you!
nicely explained !!it was being very difficult to understand the double checked locking and use of volatile in singleton but this video make it much more eaiser to understand.thanks!
Cool, thanks for this. It reminds me that I have seen developers arguing over whether the singleton design pattern is an anti-pattern. It would be interesting to see you explore this.
I didn't know about the constructor operations reordering, very intriguing. And the lazy loading of inner classes, where can I find the ins and out of java execution explained in videos?
Can we also say we are making it volatile so that no thread ends up looking at a cached value which might still say that the instance is null and that thread ends up creating another instance?
Interesting stuff. But as per my understanding there are multiple ways to break this singleton e.g. Reflections Multiple Class Loaders Clone Serialize and Deserialiser Correct me if I'm wrong. Is Enum is the best / unbreakable way to create singleton?
Thats correct. left those out from the video to keep it short. These days anyways we dont create singletons by hand, its always through some framework like Spring Boot which takes care of the internals.
Because once the singleton is created the next threads will still check if object is present (code before synchronised keyword) so it can just check value of volatile object and avoid locking which can be expensive
you need to understand what happens when threads use a shared variable which is not synchronized. It will have visibility problems due to optimization techniques used by the compiler to improve performance ( like reordering the instructions or cpu's not flushing the variable to memory choosing to keep it in cpu specific registers) .. By using synchronization techniques (volatile is also one) you can access these shared variables safely without visibility problems.
very great explanation thank you for teaching us, i have a doubt that why we need to null check 2 times ? when we check null in first if statement is not fine for inner synchronized block ?
Hi Devilal, here is the explanation for your question. Let's there are two threads that entered the method and successfully executed condition. Since there is a sync block only one thread(t1) is allowed to execute the body of sync and the other would be under waiting state(t2), imagine if we don't have a condition inside the sync block the other thread that was under waiting state now becomes runnable and creates another brand new object. Thus condition inside the sync block is required.
Very insteresting. I didn't really understand the part with the volatile. So from my understanding is that when intializing a Resource Object through the constructor the fields can be null ? Why would they ever be nulll, except an exception occurs? Could you please explain me that ? I would have never thought of creating an thread safe singelton through an Enum...!
oke so I read into volatile, since I never really had used it before. I think now I do understand it. So basically it ensures that the data from the cpu chache is getting send back to the main memory ?
Well, you are right about volatile and visibility of updates to threads. Though in case of double checked locking volatile's other guarantee is used which is it will not reorder the empty object to rs and calling the constructor instructions. Thus ensuring when rs is assigned the constructor call has been completed
@@DefogTech Would you rather use this pattern or the enum one ? Since using the enum one everything can just be done in one line of code. But there is also an disatvantage. Because what if you want to inherit. I don't see why you wouldn't just do this here : public class Singleton { public static final Singleton INSTANCE = new Singleton(); /* private constructor, getter, ... */ }
Agreed. That's cleaner. But it's eager loading, not lazy loading. So if Singletons are cheap to create and/or are going to used frequently then this eager pattern is better
one remark: regarding your first implementation of the singleton in a double checked manner, you can't use "this" in a static context. synchronize(this) is not permitted, but synchronize(Resource.Class) is working fine.
thats right, i missed that in the video.. static context requires locking on the class
Caution: These 3 patterns are for lazy loading an object. It should be used only when object is very expensive to create and it may or may not be actually called during lifetime of the application.
In practical scenarios we rarely need lazy load. It can impact performance when first time the method is called. Instead just eagerly create the singleton. In this case application will take some time to start, but the users/threads will not have any impact when calling the method once application is up.
Defog Tech bro your videos are very good but just to clarify that enum is not lazily load an object. Above statement is incorrect
Hi Defog Tech. I cannot express how grateful I'm for the videos you made on your channel. They are all simple, elegant, and straight to the point. I would like to see a video where you suggest a list of books that are on your bookshelf or that you're going to read. Thanks!
@@trinhduyhung8211 Thanks a lot for the kind words! I generally read articles, CS papers and such since information is very scattered. But will share whichever books I have found useful.
@@DefogTech Sure thing
@@rzahir7392 Volatile keyword tells the compiler not to do any reordering because the variable is shared between threads. So along with flushing to memory on every write (happens before) volatile also stops reordering of instructions involving the volatile variable.
Probably the best video on youtube explaining these concepts!! Please post more such videos :)
This is the best concurrency videos! Very clear and useful. Impressed by your depth of knowledge.
Thumba chennage explain madedeera . Good Job. 👏
This concept is so well explained that you have earned my subscribe. Keep helping the community and posting new videos Thanks
Excellent video!
I was looking for an explanation for the 'Double Checked Locking' and they were all very confusing or did not explain some things
but your video explained it very well.
also I learned other things like the 'volatile' keyword
Thank you!
nicely explained !!it was being very difficult to understand the double checked locking and use of volatile in singleton but this video make it much more eaiser to understand.thanks!
best explanation ever about singleton.
Best explanation 💯
Cool, thanks for this. It reminds me that I have seen developers arguing over whether the singleton design pattern is an anti-pattern. It would be interesting to see you explore this.
Very good explanation sir
I am fan of all these videos
Very nicely explained. Great. Keep the good work.
Very thorough and well explained brother.
Great video, thanks! Just one correction, we can not use synchronized (this) in a static method.
right, should've been ClassName.class instead.
@@DefogTech You might wanna pin this comment or put the correction in the description, you're doing a fantastic work btw :)
I didn't know about the constructor operations reordering, very intriguing.
And the lazy loading of inner classes, where can I find the ins and out of java execution explained in videos?
Impressive tutorial
Good explanation of this concept 👍
Great explanation!!
Thank You...You clarify concepts well.
Thanks 👍
Awesome! Thank you so much!
Also enum initializes its instances eagerly right?
Awesome!!
Just excellent :) thanks a lot
at 4:22 where 2nd and 3rd instructions need to be swap... anyway.. thank you very much sir.
Can we also say we are making it volatile so that no thread ends up looking at a cached value which might still say that the instance is null and that thread ends up creating another instance?
Sir, Can you do some more videos on the Java Design Patterns segment. Eagerly waiting for your new videos.
public Resource getExpensiveResource() shouldn't be a static method?
Nice video, One correction in static factory method you have used synchronized(this) instead it should be synchronized(Resource.class)
That's correct. Thanks for pointing out
great job. thanks!
Super.
Thanks for this awesome video :)
Thank you.
Sir if possible please make videos on spring (spring, spring mvc, spring boot, security,cloud )
Yes sir, spring Boot security basics coming next week. Have uploaded web mvc and testing related videos you can check those out
Interesting stuff. But as per my understanding there are multiple ways to break this singleton e.g.
Reflections
Multiple Class Loaders
Clone
Serialize and Deserialiser
Correct me if I'm wrong.
Is Enum is the best / unbreakable way to create singleton?
Thats correct. left those out from the video to keep it short. These days anyways we dont create singletons by hand, its always through some framework like Spring Boot which takes care of the internals.
Happen before will work in this scenario so volatile is not required but we are using is it. Please explain
Because once the singleton is created the next threads will still check if object is present (code before synchronised keyword) so it can just check value of volatile object and avoid locking which can be expensive
you need to understand what happens when threads use a shared variable which is not synchronized. It will have visibility problems due to optimization techniques used by the compiler to improve performance ( like reordering the instructions or cpu's not flushing the variable to memory choosing to keep it in cpu specific registers) .. By using synchronization techniques (volatile is also one) you can access these shared variables safely without visibility problems.
4:30 mark. Can somebody point me to documentation that states this as a fact. The part about order of steps 2 and 3.
Does the only reason of choosing synchronized block over synchronized method is performance? Otherwise we do not need double checking and all.
Yes, synchronised method with null check will also be correct but slow
very great explanation thank you for teaching us,
i have a doubt that why we need to null check 2 times ? when we check null in first if statement is not fine for inner synchronized block ?
Hi Devilal, here is the explanation for your question. Let's there are two threads that entered the method and successfully executed condition. Since there is a sync block only one thread(t1) is allowed to execute the body of sync and the other would be under waiting state(t2), imagine if we don't have a condition inside the sync block the other thread that was under waiting state now becomes runnable and creates another brand new object. Thus condition inside the sync block is required.
Very well explain!! Kudos... Just one doubt - How is the holder pattern thread safe ? Thanks :)
Thats taken care of by JVM itself. It adds temporary synchronization during init
Very insteresting. I didn't really understand the part with the volatile.
So from my understanding is that when intializing a Resource Object through the constructor the fields can be null ?
Why would they ever be nulll, except an exception occurs?
Could you please explain me that ?
I would have never thought of creating an thread safe singelton through an Enum...!
oke so I read into volatile, since I never really had used it before. I think now I do understand it. So basically it ensures that the data from the cpu chache is getting send back to the main memory ?
Well, you are right about volatile and visibility of updates to threads. Though in case of double checked locking volatile's other guarantee is used which is it will not reorder the empty object to rs and calling the constructor instructions. Thus ensuring when rs is assigned the constructor call has been completed
@@DefogTech Would you rather use this pattern or the enum one ? Since using the enum one everything can just be done in one line of code. But there is also an disatvantage. Because what if you want to inherit.
I don't see why you wouldn't just do this here :
public class Singleton {
public static final Singleton INSTANCE = new Singleton();
/* private constructor, getter, ... */
}
quantum a singleton should not be extended.
Agreed. That's cleaner. But it's eager loading, not lazy loading. So if Singletons are cheap to create and/or are going to used frequently then this eager pattern is better
Good video. I personally think an enum is the best approach. I'm curious to know if there's a situation where I shouldn't use an enum for singletons?
Generally you don't need lazy loading.. use this pattern only when object is expensive to create and might not need to be created
This code wont compile. You cant use "this" inside a static method. Please check
Please check earlier comments.