Method parameters are also located on the stack. If a parameter is an object reference, the reference is passed on the stack whereas the object remains on the heap. Also checkout my video about the Java Happens Before Guarantee - which is also part of the Java Memory Model: th-cam.com/video/oY14UyP61F8/w-d-xo.html
Im your fan, love you so much for your help. You are the only reason for i am learning java! To express my grateful respect, I subscribed you. Once i get job i will support you and will help you as much i can! I am seeing in each video how much sincere hardwork you put in these tutorials! Salute from tamilnadu, im living in pattukkottai a small town! Im a first graduate in my family! I will also help like you in future selflessly.
Man, in the beginning of the playlist I thought it would be some generic tutorial about threads. But I was so wrong. This here is just pure GOLD. Thanks, Jakob.
Hi Kamran, I am happy that you did not get disappointed :-) I have tried to really get "under the hood" to explain how threading works inside the Java VM. When you understand that, multithreaded programming gets a lot easier, and more predictable :-) ... I have a few more videos coming in this playlist in a near future. Hopefully some of them will be useful for you too :-)
Oh man.... your explanation is so good. I'm preparing for my java interviews and you have covered a lot of stuff in your playlist. Thank you for helping the community. 😬
This playlist is super helpful, I rare to find who explains practical parts linked to theoretical parts without too much abstraction or too much detail, it is just the optimum explanation
God of Concurency..i have bene flowing you since my 2014 when you used to write blog post only...by going through your post i attend interview like a LION when they ask mutithreading qns.......Thanks a Lot form 10+ yrs exp guy from BLR,India.
@@JakobJenkov hm🤔 maybe it's reasonable to add "part 1" to this video title?🙂 bwt, it's very practical to add whole playlist link in video description (U did that). It's very convenient.
It's so admirable and appreciable that you don't prefer to show ads in your videos. Your videos are concentrated and distraction free. Big thanks Mr. Jakob.
Yearh, I only have ads before and after... and sometimes a bit of overlay ads which you can remove yourself. I only have these in-video ad breaks in very long videos - and not in everyone of them.
Jakob Jenkov the level of care and detail you put into your content - videos and written tutorials alike - is absolutely mind blowing and inspiring. Nuff Respect.
Great Job Jakob, I have been architecting and developing for over 30 years and I can tell you that you really cover the permutations of what can happen and explain each use case and your use case granularity is noted how you depict how memory is shared or not based on instance or static or shared instance passed into the thread. Your methodology makes sure people have the info to get it. you don't talk bits and pieces you do a comprehensive covering and I hope people understand and appreciate your level of definition and 360 degrees of dimension which produces "understanding"
Hi Michael - thank you ! ... that is exactly what I am trying to do in my articles and videos - to provide that core understanding that enables developers to "calculate" how a given piece of Java code will behave in different situations. Predictable code gives developer confidence too. Unfortunately it often takes me a long time to figure out how to best present a given topic to provide that core understanding - meaning I don't publish as often as I would like to!
Thanks done 18:30 example on when threads will be sharing a variable vs each having its own variable. Think of the Runnable like any other object, if the same one is passed to different threads then variables declared inside that runnable will be accessed by the threads. If a new runnable or new object is created for each thread then they will be accessing completely different objects
Most any software engineer has watched, for myriad topics, hundreds of instructional videos. I must say that you are in the top tier of informational content producers. Your pairing of diagrams with code, and references to both throughout, is excellent. You do a masterful job of relaying complicated concepts to viewers with efficiency. Hats off to you!
Thank you ! ... I do spend quite a long time trying to figure out how to explain a given topic best. That is one of the reasons I do not make so many videos :-/
Great explanation. Finally, I understand how local variables work with threads and why it is important to keep this in mind trying to solve race conditions in Java concurrency. Greetings from Mexico!
Thank you ! ... Greetings back - from Denmark :-) ... I am happy my explanation helped you! ... I spent a lot of time studying this too, when I started with Java. Also, some of the details changed over the years... that's just part of the game :-)
@@JakobJenkov Denmark! aaaah, you're not english native:)) i guessed that while reading articles on your site. Very often very bad sentences structure:)
Really appreciate the video for nicely explaining the concepts and internally how it works... Unfortunately most of videos just say what is multi threading and how to implement but don't talk about the it works internally.. Thanks a lot for helping me understand multithreading better ❤
Dude you have the most relaxing voice of all time. I have trouble getting sleep in general, so I code at night when I can't sleep. But you make me sleep in 5minutes
Thank you very much for your kind words! I am happy that my tutorials are understandable! ... hard-to-understand material is a real set-back for developers learning new tech!
Your explenation was absolutely clear. It throwed light on thread race condition that I had been struggeling for years to understand proprerly, even after reading "Cuncurrency in Practice" Goetz's book ! Thank you so much!
Hey ! Great to hear! :-) I am happy that my tutorials are useful to you !! :-) I have had a bit of a "break" - or "slowdown" as I am trying to figure out what to write about going forward, so I write about something that is both useful to others, but also something I learn from myself, and find interesting myself. But I think I have figured that out now... so I hope to speed a bit up again within the next year or so.... within reason - because I also have a full time job to attend and other things :-D
Yeah. This is fantastic. A lot of presentations are pretty superficial and get people writing and starting multiple threads, but not realizing the data hazards due to shared memory. When I first played with multiple threads, I even thought I was aware of those, but would sometimes see anomalous results. I think going slowly and carefully in the first long part of the video showing what is shared and what is separate is very important in that regard, instead of just jumping into synchronized and volatile in a big hurry.
Thanks - I was actually about to upload the video without the first, detailed code walk-through... but then I decided that such an example was necessary!
Thank you very much! I've got a sequel to this video coming up which explains more advanced features of the Java memory model: The Java Happens Before Guarantee for volatile variables and synchronized blocks.
This is a really useful discussion of a difficult topic. Clear code samples, nice diagrams and well paced verbal explanations. I admire your ability and efforts to spread knowledge. Thank you so much!
You are welcome! ... in my experience, the most occurring reason why people have a hard time learning some new topic is learning materials that are hard to understand. I am trying to rectify that - to the extend I have the time!
1 subtlety which is missing from this video is the distinction between "Thread Stack" and "Call Stack within the thread stack". At 2:07, while it is correct that local variables are stored on Thread stack, they are actually stored on a call stack within the Thead stack. A call stack encapsulates the execution state (local variables, return values, program counter ...) of the currently running function.
Bit confusing. A call stack entry only stores the primitive data types and the object references. The actual object is stored in the heap. However, here he mentioned that the thread stack contains the object (and not the reference).
If I actually do say that - it's a mistake. Only the object reference is stored on the stack. The object is stored on the heap. However, at the exact time in the video that is referenced in this comment - I clearly show in the diagram that only references are stored on the stack - and the object itself is stored in the heap. And - I also explain that in the video, right there.
As another poster has already said, you deserve way more Likes. Looking forward to exploring more of your videos and text based tutorials. A huge thank you for providing this material!
At 22:22 , Thread 1 is 2 million but Thread 2 is not. I tested this locally and I see the same discrepancy. On multiple runs, a few do result in 2 million in both. I did fix it by using a CyclicBarrier right after the end of the for loop. So apparently making sure both threads do the full for loop matters. My guess for the different counts is because one Thread (it could be 1 or 2 it seems, from testing) starts just a bit before its partner. While late thread starts and is busy incrementing the count, the initial thread has already finished its for loop and prints the count. Since, the late thread hasn't completed its for loop, the counter isn't going to be 2 million yet. Then the late thread finishes and prints - this will be 2 million.
Hi Xi, if 2 threads both count to 1.000.000 - the total result should be 2.000.000 - but both threads will most often NOT reach the final count at the same time. One of the threads will typically finish its 1.000.000 iterations before the other, and thus the total count at that time is less than 2.000.000 .
Thanks a tonne once again i so wish i could work with you to get these concepts (&Java) in my blood.... like day-in day-out ... the way we breath - that's how we perceive the concepts are to you ! Cheers !
If you study and practice enough, little by little you will learn more and more and more. That's how I've learned what I know. Reading. Making small examples. Going to work and using what I learned. Reading more. etc. etc.
:-D ...you can become better than me! There are so many learning resources available today, that you can learn much faster than I could when I started out!
Third episode in and I really find your tutorial and examples really comprehensive. You use words and examples that are so easy to understand. I've been trying to get my head in concurrency for quite some time now and this is by far the best tutorial I've seen. One improvement - perhaps it would be nice to have your examples in git.
I have a few of the examples in a git repo here: github.com/jjenkov/java-examples If you browse the code, there are more examples than what are listed on the README page.
Lovely Explanation, Superb please keep doing the good work :) Came here from you blog and I am glad I watched this video. Just subscribed you and now i know where i need to end up in case i am stuck in java
Thanks :-) ... after 20+ years of working and learning in the IT industry, and 15+ years of blogging, I have realized that there is more to a good presentation of a topic than the language it is written in. My mothertoungue is Danish, but there are simply not enough materials available in Danish, so I've had to read it in English most of the time. And there is a big difference between a bad Danish book, and a good English book and the other way around too. Especially academic books can be hard to read - especially when written in a language other than your mothertongue.
Awesome tutorial! Thanks for your work! Though, it left several questions: 1. 22:56 - if Thread 2 finished first, why is it printed second? 2. It would be awesome if you mentioned the reason of different counts printed (while it is the same variable in memory) - while first thread is finished counting and printed count the second one is still uses that same variable and increments it. It's a matter of execution time. The combination of these two got me puzzled for some time :)
Great explanation of the Java Memory Model, you will already know this but volatile alone cannot be used for CAS related operations. I agree that volatile ensures all threads see the same value, but incrementing a variable can only be atomic via synchronization or by using an AtomicInteger
Yes, I know that, and I cover that in several of my videos :-) There is one situation where it can work to increment a volatile variable though: Single writer - Single / multiple reader cases. If only one thread every writes to the volatile variable, then incrementing it is safe, or using it in compare-and-swap-like situations. If only one thread writes to a volatile variable, then only that thread depends on the variable's previous value, and no conflict occurs.
@@JakobJenkov I’m not doubting that. I have seen far too many programmers who mark a shared variable volatile and when I say “that’s not thread safe” they try and argue it is because it’s volatile 😬
Hi Jacob, Great explanation really appreciate and you just got a sub 🙂 Below are two points i need to ask:- 1) The main method itself runs in a thread so the threads defined are its local variables right? 2) You said object references are stored on stack and objects on heap but what if variable is a primitive type that is they are not objects.
Yes, the local variables in main() are local to the thread running main() Primitives don't have object references to them. The primitive values are store on the stack directly.
You are really a fantastic teacher. Do you have any courses on Udemy or Pluralsight? You are a master of this topic. Can you please cover how can we write high transaction codes? Your tutorials are fun to watch and a lot to learn.
Hi Jasper, I am glad my tutorials are helpful for you! :-) ... I don't have any courses on Udemy, Pluralsight, LinkedIn Learning ... only TH-cam and Odysee, and my website jenkov.com so far :-)
Thanks, your videos are awesome. Can you please comment that why both threads didn't stop at one million even after using synchronized block? IMO they should have because as log as one thread hit million, it should come out of for loop?
Both threads loop for 1 million times in total. The for-loops do not look at the "count" variable to determine how many times to loop. They only look at their own "i" variables. That means, that the threads will both loop 1 million times, and in total that should result in 2 million loop iterations. The threads only share the "count" variable - not their "i" variables.
Nice tutorial! I have two questions, if you don't mind. One thing that is puzzling is that in the last example even though we used synchronized one thread got the count of 2 million (expected) but the other one did not? How's that possible? The other question would be, if we were to use class that "extends thread" instead of implements runnable to recreate the scenario, and we had a member field that is a reference type (for example Count count) in that class, where would that member field "live"? We created two thread stacks, but I'm not sure if "count" referencing variable would be located on thread stack since it is not "local variable" but rather member field. Where are member fields located that's sort of the main question. Hopefully my questions help others with same dilemmas :)
One thread will finish counting to 1 million before the other thread. Only one of the threads can add the last 1 to turn the total count to 2 million (2 x 1 million). A member in a Thread subclass would live within instances of that Thread subclass. Thus, each thread would end up having its own count field. Member fields are stored on the heap within with the object.
My biggest confusion is that if threads are also java objects, they would also be instantiated on heap. Moreoever, if two threads share an object and that object has state, then if both threads update that state (through setters on the shared object) then would each thread make a copy of that state in their register? Would it mean we have two copies of that state in two CPU registers, simply because we exposed that state (which is still very much part of only 1 object on heap) to two threads ?
Yes, each thread *may* hold a copy of the state of a shared object in different CPU registers at the same time. That is why we use volatile variables or synchronized blocks - which both force reads of a variable to come directly from main memory and writes to go back to main memory.
Great tutorial about multithreading and Java memory model, but one thing is missing. Diagrams are too static, when you explain different variants of code you should follow that and draw on diagram what is happening, because it will be more clearer. For example in section with local variables and object locations, for different combinations in code you are always using same diagram, so it is very confusing to realize what and which objects are created. This is just feedback from my side how to improve you tutorials
Thanks for the feedback ! I will try to think about that in future videos! :-) It's not always so easy to draw clearly the ideas I am trying to convey :-) But I will try to think more about it!
I didn't understand why Thread 2 printed 1674273 at 22:23 ? I expected them to print 2 million since access to count happening inside the synchronized block
Only the second thread will see the full count of 2 million. The two threads each increment the counter 1 million times and print the value of the counter at the time they finish incrementing 1 million times. Thus, the first thread has finished incrementing 1 million times when the total count is 1,674,273 . At that time the second thread has only incremented the counter 674,273 times.
Imagine each thread dropping a pebble into a shared bucket for each iteration. And each thread will use the total bucket count before incrementing. In the best case one thread will be 1,999,999 and the other one 2,000,000. Because one thread will finish before the other one.
I am a C++ guy with hardware experience coming to learn more Java, but I noticed that the Hardware Architecture is not correct, the L1 and L2 cache levels are fabricated inside each core where L3 cache is shared between cores inside the CPU chip (most modern CPUs are fabricated like this), also the Thread itself is on RAM that will be loaded later to cache and CPU fetch thread instructions from cache and in case of a cache miss those instructions are fetched from RAM, the JVM can't do anything about this
This is already mentioned by others in the comments - and has been addressed in later videos. Regardless, whether the illustrated architecture is not 100% doesn't actually change the message of the video - that variables may be stored in either CPU registers or memory (L1, L2, L3 or RAM), and that unless the variables value is written from CPU register to memory, you risk thread visibility errors. It doesn't really matter whether the CPU or Java "flushes" variables from CPU register to the cache + RAM or not - as long as it happens.
Method parameters are also located on the stack. If a parameter is an object reference, the reference is passed on the stack whereas the object remains on the heap. Also checkout my video about the Java Happens Before Guarantee - which is also part of the Java Memory Model: th-cam.com/video/oY14UyP61F8/w-d-xo.html
Im your fan, love you so much for your help. You are the only reason for i am learning java!
To express my grateful respect, I subscribed you. Once i get job i will support you and will help you as much i can!
I am seeing in each video how much sincere hardwork you put in these tutorials!
Salute from tamilnadu, im living in pattukkottai a small town!
Im a first graduate in my family! I will also help like you in future selflessly.
Man, in the beginning of the playlist I thought it would be some generic tutorial about threads. But I was so wrong. This here is just pure GOLD. Thanks, Jakob.
Hi Kamran, I am happy that you did not get disappointed :-) I have tried to really get "under the hood" to explain how threading works inside the Java VM. When you understand that, multithreaded programming gets a lot easier, and more predictable :-) ... I have a few more videos coming in this playlist in a near future. Hopefully some of them will be useful for you too :-)
thanks for this comment bud, after viewing your comment i didn't skipped this video and watched it fully and I agree with you this 24 karots
you deserve more subs. your vids are awesome.
Thank you very much :-)
Agreed!
Agreed!
!
One of the best tutorials out there.. This is literally a goldmine.. Thanks a lot
Thank you very much !! 😊
Oh man.... your explanation is so good. I'm preparing for my java interviews and you have covered a lot of stuff in your playlist. Thank you for helping the community. 😬
You are welcome!! :-)
You explain so well. I have been your follower since college, and now I am a software engineer. Great work, really appreciate 😊
Thank you very much for your kind words :-) I am happy that I have been able to help you! :-)
I am never see such detailed explanation about threads as this. Thank you Jakob. Pls never remove this videos. We would need it until lifetime)
Thank you very much - glad my video helped you :-)
This playlist is super helpful, I rare to find who explains practical parts linked to theoretical parts without too much abstraction or too much detail, it is just the optimum explanation
Thank you :-) ... yes, I try to explain the theory in a way that a practitioner needs to know it - not like some academic would phrase it ;-)
Your tutorials are absolutely fantastic and have taught me so much, thank you.
I am happy to hear that :-)
God of Concurency..i have bene flowing you since my 2014 when you used to write blog post only...by going through your post i attend interview like a LION when they ask mutithreading qns.......Thanks a Lot form 10+ yrs exp guy from BLR,India.
Thank you for your kind words ! :-)
Your videos on multithreading are the best explanation I have come across in 20 years of java exp.
Thank you very much for your kind words! :-) Glad the tutorials are helpful!
I'm preparing for the OCA exam, and this was exactly what I needed.
I thank you Jakob from the bottom of my heart.
You are welcome! ... remember to also watch Part 2 about the Java Memory Model - the Happens Before Guarantee video!
@@JakobJenkov
hm🤔 maybe it's reasonable to add "part 1" to this video title?🙂
bwt, it's very practical to add whole playlist link in video description (U did that). It's very convenient.
It's so admirable and appreciable that you don't prefer to show ads in your videos. Your videos are concentrated and distraction free. Big thanks Mr. Jakob.
Yearh, I only have ads before and after... and sometimes a bit of overlay ads which you can remove yourself. I only have these in-video ad breaks in very long videos - and not in everyone of them.
This is the best explanation for threads on the internet and even in the libraries of the entire world!
Thank you very much :-) ... remember to also watch my follow-up video "The Happens Before Guarantee" - to fully understand the Java memory model !
Jakob Jenkov the level of care and detail you put into your content - videos and written tutorials alike - is absolutely mind blowing and inspiring. Nuff Respect.
Thank you very much for your kind words! I appreciate that! And - I am happy that you find my videos useful :-)
Great Job Jakob, I have been architecting and developing for over 30 years and I can tell you that you really cover the permutations of what can happen and explain each use case and your use case granularity is noted how you depict how memory is shared or not based on instance or static or shared instance passed into the thread. Your methodology makes sure people have the info to get it. you don't talk bits and pieces you do a comprehensive covering and I hope people understand and appreciate your level of definition and 360 degrees of dimension which produces "understanding"
Hi Michael - thank you ! ... that is exactly what I am trying to do in my articles and videos - to provide that core understanding that enables developers to "calculate" how a given piece of Java code will behave in different situations. Predictable code gives developer confidence too. Unfortunately it often takes me a long time to figure out how to best present a given topic to provide that core understanding - meaning I don't publish as often as I would like to!
Best explanation of Java concurrency hands down. Thank you Jakob
Thanks ! :-)
Thanks done
18:30 example on when threads will be sharing a variable vs each having its own variable. Think of the Runnable like any other object, if the same one is passed to different threads then variables declared inside that runnable will be accessed by the threads. If a new runnable or new object is created for each thread then they will be accessing completely different objects
nice addition.
Most any software engineer has watched, for myriad topics, hundreds of instructional videos. I must say that you are in the top tier of informational content producers.
Your pairing of diagrams with code, and references to both throughout, is excellent. You do a masterful job of relaying complicated concepts to viewers with efficiency. Hats off to you!
Thank you ! ... I do spend quite a long time trying to figure out how to explain a given topic best. That is one of the reasons I do not make so many videos :-/
Great explanation. Finally, I understand how local variables work with threads and why it is important to keep this in mind trying to solve race conditions in Java concurrency.
Greetings from Mexico!
Thank you ! ... Greetings back - from Denmark :-) ... I am happy my explanation helped you! ... I spent a lot of time studying this too, when I started with Java. Also, some of the details changed over the years... that's just part of the game :-)
@@JakobJenkov
Denmark! aaaah, you're not english native:)) i guessed that while reading articles on your site. Very often very bad sentences structure:)
this tutorial and how you slowly present your ideas with examples is too underrated!
You need more subs, views and exposure in general!
Thank you Reynaldo :-)
Really appreciate the video for nicely explaining the concepts and internally how it works... Unfortunately most of videos just say what is multi threading and how to implement but don't talk about the it works internally..
Thanks a lot for helping me understand multithreading better ❤
What do you mean by "works internally" ?!?
Dude you have the most relaxing voice of all time. I have trouble getting sleep in general, so I code at night when I can't sleep. But you make me sleep in 5minutes
I am not sure if that is a good thing - or a bad thing ;-)
Best explanation I have ever seen...
Thank you very much !! :-)
Any knowledge written in your blog is very important to me ,i have never found a engineer who written the same content better than you,thanks +
Thank you very much for your kind words! I am happy that my tutorials are understandable! ... hard-to-understand material is a real set-back for developers learning new tech!
Your explenation was absolutely clear. It throwed light on thread race condition that I had been struggeling for years to understand proprerly, even after reading "Cuncurrency in Practice" Goetz's book ! Thank you so much!
I am happy to hear that!!! ... you are very welcome! :-)
thanks you Jakob, I hadnt see tutorials like yours ever. your tutorials are simple and easy to understood, i like it.
Thank you very much !! :-)
jakob i follows you from starting of my career...your tutorials are clear and well explained!!!
Hey ! Great to hear! :-) I am happy that my tutorials are useful to you !! :-)
I have had a bit of a "break" - or "slowdown" as I am trying to figure out what to write about going forward,
so I write about something that is both useful to others, but also something I learn from myself, and find interesting myself.
But I think I have figured that out now... so I hope to speed a bit up again within the next year or so.... within reason - because
I also have a full time job to attend and other things :-D
You are the most amazing tutor I have ever had. Kudos to your teaching skills.
Thank you very much! :-D
Yeah. This is fantastic. A lot of presentations are pretty superficial and get people writing and starting multiple threads, but not realizing the data hazards due to shared memory. When I first played with multiple threads, I even thought I was aware of those, but would sometimes see anomalous results. I think going slowly and carefully in the first long part of the video showing what is shared and what is separate is very important in that regard, instead of just jumping into synchronized and volatile in a big hurry.
Thanks - I was actually about to upload the video without the first, detailed code walk-through... but then I decided that such an example was necessary!
You are very good in arranging and describing the information. Very nice video.
Thank you very much! I've got a sequel to this video coming up which explains more advanced features of the Java memory model: The Java Happens Before Guarantee for volatile variables and synchronized blocks.
This is a really useful discussion of a difficult topic. Clear code samples, nice diagrams and well paced verbal explanations. I admire your ability and efforts to spread knowledge. Thank you so much!
You are welcome! ... in my experience, the most occurring reason why people have a hard time learning some new topic is learning materials that are hard to understand. I am trying to rectify that - to the extend I have the time!
Guruji @jakobJenkov no words to describe.you made this complicated topic very easy.Thank you saw muchhhh
Thank you very much! :-) I am happy my video has helped you!! :-)
1 subtlety which is missing from this video is the distinction between "Thread Stack" and "Call Stack within the thread stack". At 2:07, while it is correct that local variables are stored on Thread stack, they are actually stored on a call stack within the Thead stack. A call stack encapsulates the execution state (local variables, return values, program counter ...) of the currently running function.
Bit confusing. A call stack entry only stores the primitive data types and the object references. The actual object is stored in the heap. However, here he mentioned that the thread stack contains the object (and not the reference).
If I actually do say that - it's a mistake. Only the object reference is stored on the stack. The object is stored on the heap. However, at the exact time in the video that is referenced in this comment - I clearly show in the diagram that only references are stored on the stack - and the object itself is stored in the heap. And - I also explain that in the video, right there.
@@JakobJenkov you mentioned it right bud no issues
Thank you Jakob for all your efforts and shared knowledge. With your videos learning such complex topic is a breeze!
Great !! :-)
As another poster has already said, you deserve way more Likes. Looking forward to exploring more of your videos and text based tutorials. A huge thank you for providing this material!
Thank you very much! :-)
I really appreciate all the details you give out in your tutorials! I've been learning so much with you... keep it up :)
I am happy to hear that! :-)
Great explanation!
Thanks :-)
At 22:22 , Thread 1 is 2 million but Thread 2 is not. I tested this locally and I see the same discrepancy. On multiple runs, a few do result in 2 million in both. I did fix it by using a CyclicBarrier right after the end of the for loop. So apparently making sure both threads do the full for loop matters.
My guess for the different counts is because one Thread (it could be 1 or 2 it seems, from testing) starts just a bit before its partner. While late thread starts and is busy incrementing the count, the initial thread has already finished its for loop and prints the count. Since, the late thread hasn't completed its for loop, the counter isn't going to be 2 million yet. Then the late thread finishes and prints - this will be 2 million.
Hi Xi, if 2 threads both count to 1.000.000 - the total result should be 2.000.000 - but both threads will most often NOT reach the final count at the same time. One of the threads will typically finish its 1.000.000 iterations before the other, and thus the total count at that time is less than 2.000.000 .
Thank you Jakob, nice explanation
Glad you liked it ! :-)
Thanks a tonne once again
i so wish i could work with you to get these concepts (&Java) in my blood.... like day-in day-out ... the way we breath - that's how we perceive the concepts are to you !
Cheers !
If you study and practice enough, little by little you will learn more and more and more. That's how I've learned what I know. Reading. Making small examples. Going to work and using what I learned. Reading more. etc. etc.
Few tutorials will link it to the hardware. You are doing a great job!
Thanks !
Very good explanation! Good level of depth knowledge about Threads and CPU arch! Congrats again for the great summariazation!
Thank you! :-)
So happy to see you have a channel. I've been using your tutorials online and they're awesome.
Thank you very much! I am happy you found my channel then! :-)
Your videos and website tutorials are just fantastic! Thanks!
Thanks! :-)
Thank you very much!
Your explanation and examples are really helpful.
I wish you the best and motivation to create more such good content!
Thank you very much ! :-)
More Java tutorials please! 👍
I will try ! :-)
Woww!!! That was a very good explanation .. learned a lot in a single !! video over to the next one ;)
I am happy to hear that! :-)
Thank you Jacob for this pretty clear explanation , good job
You are welcome! I am glad it was useful :-)
Excellent Jakob! Excellent presentation! Thank you!
You are welcome! :-)
Dude your explanation is awesome. Thanks for that quality of content. Please keep going
Thanks! :-) ... I will continue - when I have time :-)
Awesome videos, as other people stated. Keep them coming, your work really helped me understand concepts that other teachers couldn't explain !
Thanks - will try :-) ... which teachers?
Thank you so much Jakob for creating such wonderful videos and presenting them in so easy to understand way.
You are very welcome :-) Glad my videos help you! :-)
You explanation is awesome. I want to be like you one day
:-D ...you can become better than me! There are so many learning resources available today, that you can learn much faster than I could when I started out!
This really good content low level java understanding with coverage of multithreading.
Thanks :-) ... I try hard! ... though it's not that easy to find precise information about these topics, so it's not that fast to make videos about!
Third episode in and I really find your tutorial and examples really comprehensive. You use words and examples that are so easy to understand. I've been trying to get my head in concurrency for quite some time now and this is by far the best tutorial I've seen.
One improvement - perhaps it would be nice to have your examples in git.
I have a few of the examples in a git repo here:
github.com/jjenkov/java-examples
If you browse the code, there are more examples than what are listed on the README page.
Lovely Explanation, Superb please keep doing the good work :) Came here from you blog and I am glad I watched this video. Just subscribed you and now i know where i need to end up in case i am stuck in java
Thank you very much for your kind words! :-)
Thank you for the video!
You are welcome!
Good explanation, thank you Jakob!
You are welcome ! :-)
Perfect video. Thank you!
You are welcome! :-)
Great explanation 👌. Thank you for your work.
You arr welcome :-)
Good one, quite helpful. Thanks Jakob.
You are welcome :-)
English is not my native language but I can understand this video better rather than some videos about the same subject on my native language!
Thanks :-) ... after 20+ years of working and learning in the IT industry, and 15+ years of blogging, I have realized that there is more to a good presentation of a topic than the language it is written in. My mothertoungue is Danish, but there are simply not enough materials available in Danish, so I've had to read it in English most of the time. And there is a big difference between a bad Danish book, and a good English book and the other way around too. Especially academic books can be hard to read - especially when written in a language other than your mothertongue.
Thanks Jakob, these are some amazing videos!
You are welcome! Glad you like them! :-)
Amazing tutorial. Thank you for your work!
Thanks - and you are welcome! :-)
nice, nice lesson.
read a few lessons in text, now am covering them with video. can notice video is more detailed.
Thank you! Great to hear! :-)
@@JakobJenkov
really nice job, man. detailed. not in a hurry.
it's a creative trace of your life.
wish i will make something like that.
this is mindblowing, love the vid, thanks
Glad you liked it :-)
Thank you very much for the videos.
they make the subject easy to understand.
Keep it up and once again thank you :).
Thank you for your feedback! ... I have many more videos planned - it's mostly a question of getting the time to record them :-)
Awesome content, so clear!!
Thank you ! :-)
Awesome tutorial! Thanks for your work!
Though, it left several questions:
1. 22:56 - if Thread 2 finished first, why is it printed second?
2. It would be awesome if you mentioned the reason of different counts printed (while it is the same variable in memory) - while first thread is finished counting and printed count the second one is still uses that same variable and increments it. It's a matter of execution time.
The combination of these two got me puzzled for some time :)
Concurrency will get you puzzled from time to time in any case :-D ... still happens to me too sometimes ;-)
I think it's because Threads have a nondeterministic behavior in where external/internal conditions could affect the way your thread produces.
Wonderful tutorials! Thank you a lot!
You're very welcome! :-)
Man that tutorial is amaizing !!!
Thanks! Great to hear! :-)
Thanks a lot Jakob!
You are very welcome :-)
Thank you, bro
Nice work!
Thanks - and you are welcome ;-)
So professional!respect!
Thank you 😊
Great explanation of the Java Memory Model, you will already know this but volatile alone cannot be used for CAS related operations. I agree that volatile ensures all threads see the same value, but incrementing a variable can only be atomic via synchronization or by using an AtomicInteger
Yes, I know that, and I cover that in several of my videos :-)
There is one situation where it can work to increment a volatile variable though:
Single writer - Single / multiple reader cases.
If only one thread every writes to the volatile variable, then incrementing it is safe, or using it in compare-and-swap-like situations. If only one thread writes to a volatile variable, then only that thread depends on the variable's previous value, and no conflict occurs.
@@JakobJenkov I’m not doubting that. I have seen far too many programmers who mark a shared variable volatile and when I say “that’s not thread safe” they try and argue it is because it’s volatile 😬
Good one, mate
Thank you! :-)
Amazing explanation.
Thanks :-)
Very good explanation.
Thanks :-) ... remember to also watch the Java Happens Before Guarantee video - to get the full picture of the Java Memory Model!
Awesome tutorials!
Thank you very much !!! 😊
perfect explanation
Thank you :-)
Thanks for your work!
My pleasure! :-)
well explained 👏
Thank you :-)
Hi Jacob, Great explanation really appreciate and you just got a sub 🙂
Below are two points i need to ask:-
1) The main method itself runs in a thread so the threads defined are its local variables right?
2) You said object references are stored on stack and objects on heap but what if variable is a primitive type that is they are not objects.
Yes, the local variables in main() are local to the thread running main()
Primitives don't have object references to them. The primitive values are store on the stack directly.
Great!
Thanks! :-)
Thank you
Welcome!
You are really a fantastic teacher. Do you have any courses on Udemy or Pluralsight? You are a master of this topic. Can you please cover how can we write high transaction codes? Your tutorials are fun to watch and a lot to learn.
Hi Jasper, I am glad my tutorials are helpful for you! :-) ... I don't have any courses on Udemy, Pluralsight, LinkedIn Learning ... only TH-cam and Odysee, and my website jenkov.com so far :-)
@@JakobJenkov Thanks!
Thanks, your videos are awesome. Can you please comment that why both threads didn't stop at one million even after using synchronized block? IMO they should have because as log as one thread hit million, it should come out of for loop?
Both threads loop for 1 million times in total. The for-loops do not look at the "count" variable to determine how many times to loop. They only look at their own "i" variables. That means, that the threads will both loop 1 million times, and in total that should result in 2 million loop iterations. The threads only share the "count" variable - not their "i" variables.
@@JakobJenkov oops my bad. Hats off sir. Your videos are really good. Thanks a lot
Excellent explanation. Could you share with us images of those diagrams?
I wish I could give you more likes
:-D ... well, I appreciate every like my videos get - even if just one at a time ;-)
this is a great video thank you
You are welcome! Glad you liked it! :-)
Hidden gem..
Thanks :-)
so good
Thanks :-)
thanks!
Welcome! :-)
Nice tutorial! I have two questions, if you don't mind. One thing that is puzzling is that in the last example even though we used synchronized one thread got the count of 2 million (expected) but the other one did not? How's that possible?
The other question would be, if we were to use class that "extends thread" instead of implements runnable to recreate the scenario, and we had a member field that is a reference type (for example Count count) in that class, where would that member field "live"? We created two thread stacks, but I'm not sure if "count" referencing variable would be located on thread stack since it is not "local variable" but rather member field. Where are member fields located that's sort of the main question.
Hopefully my questions help others with same dilemmas :)
One thread will finish counting to 1 million before the other thread. Only one of the threads can add the last 1 to turn the total count to 2 million (2 x 1 million).
A member in a Thread subclass would live within instances of that Thread subclass. Thus, each thread would end up having its own count field. Member fields are stored on the heap within with the object.
My biggest confusion is that if threads are also java objects, they would also be instantiated on heap. Moreoever, if two threads share an object and that object has state, then if both threads update that state (through setters on the shared object) then would each thread make a copy of that state in their register? Would it mean we have two copies of that state in two CPU registers, simply because we exposed that state (which is still very much part of only 1 object on heap) to two threads ?
Yes, each thread *may* hold a copy of the state of a shared object in different CPU registers at the same time. That is why we use volatile variables or synchronized blocks - which both force reads of a variable to come directly from main memory and writes to go back to main memory.
Great tutorial about multithreading and Java memory model, but one thing is missing. Diagrams are too static, when you explain different variants of code you should follow that and draw on diagram what is happening, because it will be more clearer. For example in section with local variables and object locations, for different combinations in code you are always using same diagram, so it is very confusing to realize what and which objects are created. This is just feedback from my side how to improve you tutorials
Thanks for the feedback ! I will try to think about that in future videos! :-)
It's not always so easy to draw clearly the ideas I am trying to convey :-)
But I will try to think more about it!
I didn't understand why Thread 2 printed 1674273 at 22:23 ? I expected them to print 2 million since access to count happening inside the synchronized block
Only the second thread will see the full count of 2 million. The two threads each increment the counter 1 million times and print the value of the counter at the time they finish incrementing 1 million times. Thus, the first thread has finished incrementing 1 million times when the total count is 1,674,273 . At that time the second thread has only incremented the counter 674,273 times.
@@JakobJenkov doesn't that mean that "Thread 2 : 1674273" should be printed first as Thread 2 finished first?
Imagine each thread dropping a pebble into a shared bucket for each iteration. And each thread will use the total bucket count before incrementing. In the best case one thread will be 1,999,999 and the other one 2,000,000. Because one thread will finish before the other one.
you are the best
Thanks :-D
I am a C++ guy with hardware experience coming to learn more Java, but I noticed that the Hardware Architecture is not correct, the L1 and L2 cache levels are fabricated inside each core where L3 cache is shared between cores inside the CPU chip (most modern CPUs are fabricated like this), also the Thread itself is on RAM that will be loaded later to cache and CPU fetch thread instructions from cache and in case of a cache miss those instructions are fetched from RAM, the JVM can't do anything about this
This is already mentioned by others in the comments - and has been addressed in later videos. Regardless, whether the illustrated architecture is not 100% doesn't actually change the message of the video - that variables may be stored in either CPU registers or memory (L1, L2, L3 or RAM), and that unless the variables value is written from CPU register to memory, you risk thread visibility errors. It doesn't really matter whether the CPU or Java "flushes" variables from CPU register to the cache + RAM or not - as long as it happens.