ThreadLocal in Java
Вставка
- Опубліковано 17 жов 2024
- 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 ua-cam.com/video/4ZLkbWWpkyk/v-deo.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.
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.
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
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!
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
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.
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
@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
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.
number of likes are misproportioned to the quality content you have provided. great job
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 video as always, however I have a question regarding the service example. If we have a shared object that's used by multiple services, then were does it live? In other words, I'm having a hard time wrapping my head around this example. I feel like if the user context holder is supposed to be shared across multiple services, then it would have to be implemented as a distributed object running externally to the services (e.g. memcached).
Said another way, since the user context holder would be local to the request thread then how would an external service have visibility into the threadlocals running inside a different JVM? For example, service1 gets a request and gets a thread local user context object that it populates before calling service 2. When service 2 is called by service1, service2 gets its own request thread (because it's a different service running on a different jvm). Thoughts?
Ah, valid question. That's my bad. All the services live in same jvm. It's not a microsevices architecture. With services I meant classes involved in processing the flow. Since controller in spring accepts the request and then asks 1 or more @service classes to process the request, I mentioned service in the diagram.
@@DefogTech On the same line, in case of microservice architecture (where services might run in different JVM or possibly on different servers) how threadlocal is helpful? e.g. service 1 deployed on server 1, service 2 deployed on server 2. Now a request coming to service 1 from user X, service 1 does some enrichment to User object and want to pass it to service 2. How that can be achieved using Threadlocal? If not possible with THreadLocal do we have any alternate way?
Shivraj Jadhav - May be If I understood question . Microservices do run independently in a jvm. Not sure how you could have thread safety issue among multiple jvms running their own heap.
@@DefogTech Yeah , please make an annotation on the video or make a pinned disclaimer so people don't get confused by. Great video by the way!
@@DefogTech Thanks so much for the response and the pin! Really love your videos :)
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!!
Thanks a bunch for this video. Nice explanation. One request - can you explain the data integrity issue mentioned at 02:54 with an example for my clarity please?
Its great. Short and sweet. Straight to the point! Thank you
Absolutely brilliant. Crystal clear explanation. Thanks man.
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.
I think your good expertise in concurrency you are doing great job
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. :)
The best explanations on the internet
Can you please some videos on RequestContextHolder & SecurityContextHolder ? Your videos are so precise and clear. please keep making good videos.
Nice video.
@7.28 shouldnt those services be in parallel in the diagram instead of being sequential ?
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?
Man, you nailed the explanation. Thanks a lot.
I'm from China,your video is very awesome!Keep going!
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?
At 9:43, why do we put the clean up process in Service4? How do we know other services have consumed `User` when Service4 runs? Don't all the services run asynchronously?
Boss you nailed it. Your way of explaining complex things makes it very easy to understand. Thanks and keep posting more videos :)
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?
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.
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?
Thanks...your explanation is really good, straight to the point
Excellent videos on Java Concurrency with Real world examples ... Please post some videos on DS and algo as well
Explanation is really good to understand the concepts. Could you please share/upload any video on L1/L2/L3 cache models
At 2:01 you say all 1000 tasks will create there own SimpleDataFormat(SDF) object, so there will be a total of 1000 SDF objects. But is it? Since, we have a fixed thread pool of size 10, at any given point in time, there will be at most 10 threads running and so, at most 10 SimpleDateFormat objects should be there in heap, all of the other tasks would have either completed or would be waiting to be running state. Or am I missing something here?
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 ).
Very useful, clear and concise, would be helpful if you provide some insights on Inheritable Thread local and difference with Thread local.
He explained it so well.
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.
One quick question, `SimpleDateFormatter` is the class, that is not mutating any property. If multiple threads share the same(global) object of `SimpleDateFormatter`, in that case, what is the data integrity issue is? Because as I thought, if we are reading the value only, not mutating, in that case, there will be no issue. Could your please correct me?
Valid question. The code for github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/java/text/SimpleDateFormat.java shows that it uses lot of class level variables instead of static methods or method variables to store Pattern, Locale and Calendar (in abstract parent class).
Have a question.
If a single thread is managing multiple requests, would the objects of the requests get shared between these requests in the same thread (which shouldn't happen ideally)?
Or, is one thread dedicated to only one request? In that case, why would ThreadLocal be required as there is no object per thread but instead object per task (request)?
Thanks for the video.
ThreadLocal will be 1 per thread. Considering a thread can only handle one request at a time, every request will use the thread-local, and reset its value once request is completed, thus it will be ready for next request to use.
Cleanup is necessary for ThreadLocal, however, if used in SimpleDateFormatter, where is the point once should do the cleanup. It will always be used.
Can you provide a Thread local sample using String builder instead of Simpledateformat ?
3:50 how it will serve 10 sdf objects for 1000 users..again it is a data consistency problem right. Pls clarify
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!!!
Awesome , very beautifully explained.Keep up the great work
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?
Quality content on Java concurrency
Now how would you change this code if you're using project loom virtual threads? 🤔
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.
your vids are truly informative
What happens in case ThreadLocal is updating reference type will it not effect object shared by other threads
You are awesome man....thank you so much for doing this.
isn't at 2:08 , only 100 dateformat objs would be created since others would be GCed at a given interval of time.
You are amazing ... Superb explanations like always
Excelent explanation! Very useful examples!
Thanks !! Can you try make video on Jndi context ....I want to listen this concept by you ....
Awesome tutorial thank you very much!
Even SimpleDateFormat object is not thread safe when declared at global level, is this going to change anything, no, it's simply returning dateFormat. Correct me if I'm wrong.
Very good tutorial...but I request you to put part number in Java concurrency playlist.
can you pls share the ppt that you used while teaching?
what is different between task and thread @DefogTech
bro may u get blessed with twins and quadraplets and each son or daughter of yours keep creating technical content for this youtube channel
😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂
Thanks,
So nicely explained
where were you until now? as always awesome stuff.
Thanks for the video. Liked first, watching next. :). Definitely one of best video of Yours. Keep going.
*Clarification:*
2:25, If i have util class to do that formatting with static method, will effect be same ?
Thank you ma'am for the kind words!
Util class will not help since as per the API documentation, the SimpleDateFormat is not thread-safe (was a surprise for me too).
Checkout 'synchronization' section in the link - docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html
Awesome explanation
Awesome and clear explanation
amazing content, i am new to multithreading, can anyone please guide me why we are making the threadLocal variables into every example shown as static ?.. i mean even if its created per object, then also the framework might be able to handle it right?.. like by which thread accessed it, or not, i am really confused behind the secret to make this threadLocal variable as static..
can anyone please guide.. thanks in advance.
Please share the whole code for passing thread local within services. Thanks for amazing Tutorial
greattt... holder part was very good example
Best explanation ever.
Clearly explained. Thanks
Would you like to recommend any Java book which explains as concisely and lucidly as you?
For java concurrency, I found java concurrency in practice by Brian Geotz very good. It's a dense book though, helps to read couple of times.
Better than the best 💖
Great Video.
Wow just excellent !!!
Just one doubt. If an Executor is used to process only 10 threads at a time,so even if local object of SDF is used, only 10 objects will be created. How is threadlocal saving memory in this case?
How do you ensure there is only one object per thread? Because we only submit tasks we don't write code for threads in executor service
Superb 👏 thanks ...thanks once again.....
great explanation
thanks for the explanation .
Awesome channel 🎉🎉
Good video .. please keep on post this kind of video
Great video
How is that possible that different servers see the same thread?
great Videos :) Can you please do some Videos about Actor Model in Java ?
Wonderful 🙏🏿
From ur chanell itself i got 3 concurrency interview questions .
Finally got rejected and after rejection mail youtube sujjested me ur video
One question,When to use ThreadLocals and when to use Synchronization/Locks?
In my experience you almost never need ThreadLocal, while use of locks is much higher. Only for specific use-cases mentioned in the video you will need ThreadLocal.
when you want to work with global transactions(Transactions) then you must and should use threadLocal.
Covered this one too! Thank you Deepak!!
now I understand why we have TheadLocal
Very well explained
Very well explained!!
Great job, man.
Thank you brother for the clear explanation
You're welcome!
a great video. Best thanks
Great video, thank you