ThreadLocal in Java
Vložit
- čas přidán 28. 12. 2018
- Use ThreadLocal for thread-safety, memory efficiency and for per-thread context storage.
Channel
----------------------------------
Complex concepts explained in short & simple manner. Topics include Java Concurrency, Spring Boot, Microservices, Distributed Systems etc. Feel free to ask any doubts in the comments. Also happy to take requests for new videos.
Subscribe or explore the channel - / defogtech
New video added every weekend.
Popular Videos
----------------------------------
What is an API Gateway - • What is an API Gateway?
Executor Service - • Java ExecutorService -...
Introduction to CompletableFuture - • Introduction to Comple...
Java Memory Model in 10 minutes - • Java Memory Model in 1...
Volatile vs Atomic - • Using volatile vs Atom...
What is Spring Webflux - • What is Spring Webflux...
Java Concurrency Interview question - • Java Concurrency Inter...
thanks for great video!
One question, at 2:55, since all threads just read the same single global SimpleDateFormat obj, however, no thread tries to change it although it is mutable. How can the data integrity issue turn up? Can I still consider SimpleDateFormat obj as thread safe in your example?
Of course, we can ensure the data integrity of SimpleDateFormat obj when necessary by using, ThreadLocal, AtomicReference
True. If SDF only had global state variable, set only once during Constructor, we would not have thread-safety problem. Unfortunately, multiple global variables (eg: calendar) are modified even when format() method is called. Thus if 2 threads use same SDF object, and both call format() at the same time, one thread's format() will call calendar.setTime(date) and then other thread will do the same overriding first thread's date. Thus we need external sync over whole object, or have to use ThreadLocal.
Source Code (check format method)
hg.openjdk.java.net/jdk6/jdk6/jdk/file/39e8fe7a0af1/src/share/classes/java/text/SimpleDateFormat.java
@@DefogTech Oh I see. But I hope there is a more general case to illustrate this. And Java 8 has introduces DateTimeFormatter to make it immutable, thread-safe
hg.openjdk.java.net/jdk6/jdk6/jdk/file/39e8fe7a0af1/src/share/classes/java/text/SimpleDateFormat.java#l330
@@DefogTech How about making the SDF Final? Also if the SDF itself is not changing I did not understand how it impacts the other objects like Calendar? BTW Great work. This Concurrency playlist is awesome. Do you have word of PPT of these tutorials?
@@rakspatel5159 final just prevents reassignment of the reference. The problem is that sdf is not immutable - its state changes when it is used to format a date.
There is no other tutorial on Java Concurrency which is even half good as yours. Thank you Sir for making these videos. Keep it coming.
Yes.but also watch this one czcams.com/video/4ZLkbWWpkyk/video.html
Look for Jakob Jenkov. He is also on the level.
Also, this guy's (defog tech) pronunciation is awful.
@@manOfPlanetEarth Jenkov's vids are also good, but Defog's are older than him.. Both are quality providers.
@@theunusual4566
Yeah, they both set the level. Love them both.
And Geekific as well (discovered him recently, after my above text).
This is guy is one of the most inspiring geniuses I've ever met
After watching your videos, I removed all AsyncTask from my android Java code and introduced Java concurrency. Your videos about multithreading are awesome.
Seeing this after 4 years -it is a gem ! ,I have gone through several tutorials ,I understand and forgot over time ,the way you are explaining wont let you forget even if you want to be :) ,great work and god bless
Good Job in a span of 2 day I watched multiple videos and I can tell you your content is enriching for the experienced professionals as well.
Keep it up.
2:00
ThreadLocal creates a separate copy of the object for each thread.
To avoid multiple threads accessing the same object which isn’t thread safe. Multiple threads can access the same object with locks but that decreases performance. This also avoids each runnable task submitted to a thread pool creating its own object because we can have thousands of runnable
5:10 implementation
6:19 can be used to store variable like user, which needs to be passed from one service to the next. Instead of passing it as a param from one thread to the next, we can use threadlocal static variable and set it when a request comes in. So this is setting a context for a thread.
Spring uses the concept of context in these examples 8:50
Excellent explantation. In your videos, you are explaining very difficult concepts like Java concurrency to be understandable easily. Thanks for the effort. I will share this to whoever needed. Why there are no videos from you recently. Keep doing your good to work.
Absolutely brilliant. Crystal clear explanation. Thanks man.
Its great. Short and sweet. Straight to the point! Thank you
Awesome , very beautifully explained.Keep up the great work
Boss you nailed it. Your way of explaining complex things makes it very easy to understand. Thanks and keep posting more videos :)
Covered this one too! Thank you Deepak!!
Excelent explanation! Very useful examples!
Awesome tutorial thank you very much!
I think your good expertise in concurrency you are doing great job
Man, you nailed the explanation. Thanks a lot.
very nice video ！ In the second user case, “services” is little misleading, as people would think each service is running on it is own server, “handler” might be better word.
Awesome and clear explanation
You have, hands down, the best content on Java concurrency, of all the resources out there. Really really appreciate the effort you put into you videos, thank you so much for making all these concepts intuitive and easy to ingest.
Thank you for the kind words!
number of likes are misproportioned to the quality content you have provided. great job
Thanks,
So nicely explained
Thanks...your explanation is really good, straight to the point
Best way to explain is what was problem case,what is use of that component or rearm and then explain use of that teram....
Awesome explanation bro
For some reason the video thumbnail shows the video is 20mins. Thanks for the great content.
For viewers: Do write a clean up method (remove()). I forgot it once and it created a huge memory leak!!
your vids are truly informative
Great Video.
Clearly explained. Thanks
The best explanations on the internet
Wow just excellent !!!
He explained it so well.
Very well explained!!
where were you until now? as always awesome stuff.
Superb 👏 thanks ...thanks once again.....
Very well explained
Very useful, clear and concise, would be helpful if you provide some insights on Inheritable Thread local and difference with Thread local.
Excellent explanation :) Thank you
Awesome channel 🎉🎉
Good video .. please keep on post this kind of video
Notes for myself:
Threadlocal.initialize() --> sets the value of threadlocal , it is invoked automatically.
Threadlocal.get() --> used to fetch value from ThreadLocal
Threadlocal.set() --> needs to be called manually in order to set some value in ThreadLocal
Task is different from thread. 3:29 10 threads from Threadpool can do 1000 different tasks
How many threads needed for 1000 concurrent users?
How concurrent users and thread are connected?
I'm from China,your video is very awesome!Keep going!
You are awesome man....thank you so much for doing this.
Great video
great explanation
Quality content on Java concurrency
Wonderful 🙏🏿
You are amazing ... Superb explanations like always
a great video. Best thanks
Explanation is really good to understand the concepts. Could you please share/upload any video on L1/L2/L3 cache models
Great stuff, thanks! If you could please create such video to explain in the same manner how Transactions works and how to handle Transactions + CompletableFuture it would be great!
Great video, thank you
Best explanation ever.
greattt... holder part was very good example
Good as always 👌
Great job, man.
Excellent videos on Java Concurrency with Real world examples ... Please post some videos on DS and algo as well
Just perfect!
Thanks! Your video helps me))
great video
Nice video. I think while discussing you can share the latest API s like DateTimeFormatter as a better option so that viewers are aware. Thanks again for making this video.
Can you please some videos on RequestContextHolder & SecurityContextHolder ? Your videos are so precise and clear. please keep making good videos.
Awesome 😀
Thank you brother for the clear explanation
You're welcome!
Very good tutorial...but I request you to put part number in Java concurrency playlist.
bro may u get blessed with twins and quadraplets and each son or daughter of yours keep creating technical content for this youtube channel
😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂
Better than the best 💖
you awesome man thank you.
Thanks !! Can you try make video on Jndi context ....I want to listen this concept by you ....
Hi Defog,
Very interesting vlog. I like the explanation along with use cases. I have question. You have created static thread local object and then using it in instance method. Meaning static reference is accessed by non-static context. Although It is not issue but could it be not good if ThreadLocal object itself would have been non-static.
great video man :)
Thank you!
Thank you
Great content
I have one question since we can use Spring Webflux where thread can handle another request instead of waiting for IO in such cases what will haven to thread local in the 2nd Usecase?
Thanks for this playlist! Good job!!! I am just wondering if I set Request to ThreadLocal variable, and try to parse the request body a few times. Will it work only for the first time or anytime?
Please share the whole code for passing thread local within services. Thanks for amazing Tutorial
Thank You
Nice video.
@7.28 shouldnt those services be in parallel in the diagram instead of being sequential ?
Crisp and precise explanation of concepts as always.
Below are my observations and queries , please clarify.
- Use Case #1 : I understand that SDF(SimpleDateFormat) was used as example to explain the concept of ThreadLocal but for practical situations, is FastDateParser class a good alternative to SDF, which is a thread safe version of SDF. Correct me if I m missing anything here.
- Use Case #2 : In the start of the use case #2, there was a mention of usage of HashMap to store the use id across the threads but when presentation extended instead of
TheadLocal , only TheadLocal was considered; was it for simplicity of the problem ? If not, I believe TheadLocal would still be required for the scenario mentioned.
For point 1, yes it was to illustrate the problem with SDF. Practically we can use other alternative.
For point 2, it is ThreadLocal, storing user per thread. Internally java may use hashmap to achieve the effect, but from our perspective it's thread specific user.
great Videos :) Can you please do some Videos about Actor Model in Java ?
now I understand why we have TheadLocal
great!
Cleanup is necessary for ThreadLocal, however, if used in SimpleDateFormatter, where is the point once should do the cleanup. It will always be used.
your videos are awesome .. just one request whenever you explain something , implement that in program at same time.
Thanks! I could add live coding, but then videos will become too long and people don't watch long videos
@@DefogTech i think you can do it.. i am following your all videos and your explanation is great but problem is that you explain deep concept and without live code it becomes very difficult to implement..
@@KundanRoy I agree with Kundan. A great set of video tutorials Deepak. Thank you and appreciate the good knowledge sharing. Keep up the great work! I am sure such intense topics will look great when followed by a coding example. The real good learners would never dislike them ):) Cheers!!!
Thanks a ton .. can you pls clear one doubt.....Are the first and second example completely two different aspects of ThreadLocal? Because in first example we have seperate threadlocal for each thread but in second we have a global universal threadlocal with the property that it can identify threads.
If so then can we solve the first problem like the second one? Like creating a global static ThreadLocal array and each its own sdf object in the array?
thanks :)
@Defog Tech Coming with one more doubt : As you have mentioned, the SDF will be assigned to the pools of thread(instead of all the tasks) when using ThreadLocal i.e when a thread initially used to execute a task, ThreadLocal initialValue gets called and create SDF obj. Question is if this particular thread(from the pool) is reused for executing another task, will it call the get method of ThreadLocal ? If yes, then it is trying to reuse the already created SDF obj(while executing previous assigned task) which might be in some other state, and required state to run current task can be different, then how would it be threadsafe?
Yes, it's created only once and 2nd task on same thread will reuse the SDF. Within SDF format method, it sets state and uses it in next statements. So when 2nd task comes it will also set state first (overriding state set by 1st state) and then work on it. Problem only happens when 2 threads simultaneously call format method. Here both tasks of 1 thread call format method one after another
can you pls share the ppt that you used while teaching?
Sincerely appreciate your efforts. Awesome Video. Thanks a lot. I have one doubt though. We said (around 2:10) having *task local* variables (which can be reused) is not good because it creates a lot of extra objects. But wouldn't the extra objects get created only when the task is actually executed by the thread. And also once the task is done, the object will be destroyed ? In that case wouldn't we still be using 10 objects corresponding to the 10 threads at any given point in time ?
Task objects are created when we call new , so even if they are executed late by thread they still occupy heap. Also, even though object is garbage collected once thread executes the task is still creating and garbage collecting N objects as N tasks (which could be 1000s) instead of fixed number like thread local.
@@DefogTech Makes sense. Thank-you for your prompt response. :)
Thank you so much :)
You're welcome. You had asked for ThreadLocal video right? Thanks much for the suggestion.
Can you provide a Thread local sample using String builder instead of Simpledateformat ?
what is different between task and thread @DefogTech
I understand that there are many use cases of using Thread local but I could not understand the first use case and how the Thread Local is more memory efficient here.
As per my understanding ,peak memory usage would 10 date format objects in both case( as Garbage collector would remove the old once, the moment JVM terminates the task of one thread after task completion ).
What happens in case ThreadLocal is updating reference type will it not effect object shared by other threads
3:50 how it will serve 10 sdf objects for 1000 users..again it is a data consistency problem right. Pls clarify
What if the 'SimpleDateFormat' instance is stateless? At 3:02, you are saying that the SimpleDateFormat instance is not a thread safe class, but if it is stateless, then it is thread safe right.
isn't at 2:08 , only 100 dateformat objs would be created since others would be GCed at a given interval of time.
From ur chanell itself i got 3 concurrency interview questions .
Finally got rejected and after rejection mail youtube sujjested me ur video
Now how would you change this code if you're using project loom virtual threads? 🤔
Great video. I have a doubt..in the date format example when we are defining SimpleDateFormat globally i.e private static SimpleDateFormat sf = new SimpleDateFormat(..) at the top and since it is static we are eagerly loading it and we are just trying a get operation on it(ie we just need the sf object we are not modifying this object) why do we even need to make it thread safe??
SDF internally stores a state. When format mention is called it manipulates that state to calculate/format the date. If multiple threads use same SDF, the common state will cause issues to result of 2 threads.
@@DefogTech Ok. Thanks for the clarification :)
Navjot Singh SDF is not thread safe class u may find many article on it,
So its better to have it in lock.
@Defog Tech Coming with one more doubt : As you have mentioned, the SDF will be assigned to the pools of thread(instead of all the tasks) when using ThreadLocal i.e when a thread initially used to execute a task, ThreadLocal initialValue gets called and create SDF obj. Question is if this particular thread(from the pool) is reused for executing another task, will it call the get method of ThreadLocal ? If yes, then it is trying to reuse the already created SDF obj(while executing previous assigned task) which might be in some other state, and required state to run current task can be different, then how would it be threadsafe?
@@navjotsingh1081 final does not prevent one from writing to an object; it only prevents variable re-assignment. You can have a final variable pointing to a mutable object that could still be written to by multiple threads. @Defog Tech meant that SDF has instance variables whose values change when methods are called on the SDF instance. Such a class is mutable and thus not thread-safe.
If one object per thread can be stored in thread local how Spring stores different context holder in one thread local object?
Does it uses a map? And sets in the thread local? Can u share a snippet if possible?