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
@@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.
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
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.
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!!
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.
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.
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?
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
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?
@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
@@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!!!
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.
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.
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.
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?
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.
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 ).
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.
@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.
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.
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
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?
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?
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?
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.
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).
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.
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.
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?
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.
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.
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
number of likes are misproportioned to the quality content you have provided. great job
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!
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!!
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.
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.
The best explanations on the internet
Absolutely brilliant. Crystal clear explanation. Thanks man.
I'm from China,your video is very awesome!Keep going!
Its great. Short and sweet. Straight to the point! Thank you
bro may u get blessed with twins and quadraplets and each son or daughter of yours keep creating technical content for this youtube channel
😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂
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?
I think your good expertise in concurrency you are doing great job
Man, you nailed the explanation. Thanks a lot.
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?
Boss you nailed it. Your way of explaining complex things makes it very easy to understand. Thanks and keep posting more videos :)
Thanks...your explanation is really good, straight to the point
Quality content on Java concurrency
your vids are truly informative
Can you please some videos on RequestContextHolder & SecurityContextHolder ? Your videos are so precise and clear. please keep making good videos.
Awesome , very beautifully explained.Keep up the great work
He explained it so well.
You are awesome man....thank you so much for doing this.
You are amazing ... Superb explanations like always
Excelent explanation! Very useful examples!
Excellent videos on Java Concurrency with Real world examples ... Please post some videos on DS and algo as well
Better than the best 💖
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?
isn't at 2:08 , only 100 dateformat objs would be created since others would be GCed at a given interval of time.
where were you until now? as always awesome stuff.
3:50 how it will serve 10 sdf objects for 1000 users..again it is a data consistency problem right. Pls clarify
Awesome explanation
Awesome tutorial thank you very much!
@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
Thanks,
So nicely explained
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 channel 🎉🎉
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.
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.
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.
Very useful, clear and concise, would be helpful if you provide some insights on Inheritable Thread local and difference with Thread local.
Superb 👏 thanks ...thanks once again.....
Awesome and clear explanation
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?
Cleanup is necessary for ThreadLocal, however, if used in SimpleDateFormatter, where is the point once should do the cleanup. It will always be used.
Great Video.
Explanation is really good to understand the concepts. Could you please share/upload any video on L1/L2/L3 cache models
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. :)
Best explanation ever.
Wow just excellent !!!
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 ).
Good as always 👌
greattt... holder part was very good example
great explanation
Clearly explained. Thanks
Good video .. please keep on post this kind of video
Wonderful 🙏🏿
Now how would you change this code if you're using project loom virtual threads? 🤔
Can you provide a Thread local sample using String builder instead of Simpledateformat ?
Great job, man.
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.
Very well explained!!
Covered this one too! Thank you Deepak!!
What happens in case ThreadLocal is updating reference type will it not effect object shared by other threads
what is different between task and thread @DefogTech
Excellent explanation :) Thank you
can you pls share the ppt that you used while teaching?
thanks for the explanation .
Very well explained
a great video. Best thanks
Thank you brother for the clear explanation
You're welcome!
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 :)
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
Great video, thank you
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?
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?
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?
Nice video.
@7.28 shouldnt those services be in parallel in the diagram instead of being sequential ?
Very good tutorial...but I request you to put part number in Java concurrency playlist.
Thanks! Your video helps me))
Thanks !! Can you try make video on Jndi context ....I want to listen this concept by you ....
great video man :)
How is that possible that different servers see the same thread?
Awesome 😀
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.
thanks, really appreciate it.
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).
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.
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.
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?
Just perfect!
great Videos :) Can you please do some Videos about Actor Model in Java ?
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.