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: ruclips.net/video/oY14UyP61F8/видео.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 :-)
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
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. 😬
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.
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!
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.
@@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.
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:)
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!
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 :-/
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.
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!
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!
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.
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
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!
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!
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
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.
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.
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 .
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 :)
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.
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
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 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 😬
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.
:-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!
nice tutorial, thank you) Have just one question, is synchronized keyword enough to guarantee atomicity ? Don't we need to use volatile keyword as well to guarantee that the operations are performed directly via RAM?
If you use a synchronized block you do not need to use the volatile keyword around the variables accessed inside the synchronized blocks. The volatile keyword is used to provide some level of thread visibility without having to use synchronized blocks. Thus, volatile is a weaker thread synchronization mechanism, but it offers higher performance than synchronized blocks - e.g. via non-blocking concurrent algorithms and data structures.
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 RUclips 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.
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.
Even if a shared counter is volatile - the increment operation (counter++) is not atomic. The incrementation does not happen out in the memory where the volatile memory is stored. Two CPUs might load the value of the counter into a CPU register, increment it, and write that value back to the volatile variable. If both CPUs load the value 2 into a local CPU register, both will increment it to 3, and write 3 back to the memory. Even if both variables write the incremented value back to memory immediately, one of the increments will "get lost". Only writes to a volatile variable are atomic. But - an increment is a read-increment-write operation - and is thus not atomic. This is, by the way, what we have atomic operations such as compare-and-swap for. I've made a vide about that too, here: ruclips.net/video/ufWVK7CHOAk/видео.html
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.
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.
Hi @Jakob I watched this video and also read part of the documenation about the volatile. I understood that non-volatile variables does not guaranteed but volatile variables is not enough like you explain in your documentation attached to this video. I also tested the volatile instead of synchronize {} block and faced the race condition. Please, do you see any reason to use volatile modifier if it is not enough to avoid of race condition?
There are situations where you need "thread visibility" - but where the code is written in a way where no "race condition" can occur. The volatile keyword is very helpful in such situations. Look into "non-blocking concurrrent data structures" to learn more :-)
I cover that in the video. If two threads share a member variable, and that member variable is not declared volatile, nor accessed from inside a synchronized block, there is no guarantee about when each thread will read the latest value of that variable from main memory into CPU registers, nor any guarantees about when each thread will commit the latest value of the member variable back to main memory so other threads can see it. Thus, each thread may be working on "stale" local values - not seeing the changes other threads have made to the same member variable. In the case of a shared count variable which is read-then-incremented, declaring the variable volatile is not enough - because a read-check-change-write operation on the same, shared variable by multiple threads will lead to race conditions. Thus, the read-check-change-write operation must be "atomic" - which can be achieved by performing these operations within a synchronized block (or using e.g. an Atomiclong as counter etc.).
@@JakobJenkov I got it now. The reason why I asked it because I thought both threads exit at the same time.(you didn't mention this in the video). And as they have access to same variable location in memory they should print same value when both exit at same time.(even though count is different due to race condition) So according to your explanation I understood that there is no guarantee that threads exit at same time.
@@a.yashwanth I think *any* use of the count must use synchronized (or volatile) in order to get the right value. In the code example, the increment to 'count' is synchronized. The System.out is not synchronized, so i presume it uses a value from the Register or Caches?
@@michaelhughes8413 The thread that finishes incrementing first will have incremented the count by a million. At this point the count may not be 2 million yet and it may proceed to create the string that is to be printed out with this < 2 million count. Suppose this evaluation is done, but the scheduler decides to delay the System.out.print I/O call and let the other thread complete the rest of its task. Then you have the other thread incrementing the count to 2 million, creating the string, then printing it out. And finally the first thread prints out the string that now contains the old value of the count. Even if you synchornized the System.out portion, the thread that finishes first can still print a < 2 million count. The only guarantee is that it will print this < 2 million count before the other thread prints the 2 million count.
Thank you so much for the quality video! I just have one question. I recently tried hard to really grasp what the word jvm stands for. But, the word jvm is explained quite differently at different places. Watching your video, it seems like jvm is just a part of physical ram. Am I correct on this?
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.
In the separate objects class you have created an my object and you are passing that same object reference to both runnable so it's printing same object. Not because of the object reference is created in the class level in the runnable class . Correct me if I am wrong.. thanks a lot helping us to understand the concepts ...
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: ruclips.net/video/oY14UyP61F8/видео.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
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 ;-)
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 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 !! 😊
Your tutorials are absolutely fantastic and have taught me so much, thank you.
I am happy to hear that :-)
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.
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!
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!
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 :-)
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 !
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.
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! :-)
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 :-)
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:)
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 !! :-)
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! :-)
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.
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! :-)
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 :-/
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 ! :-)
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! :-)
Best explanation of Java concurrency hands down. Thank you Jakob
Thanks ! :-)
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!
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!
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.
You are the most amazing tutor I have ever had. Kudos to your teaching skills.
Thank you very much! :-D
Few tutorials will link it to the hardware. You are doing a great job!
Thanks !
Thank you Jakob for all your efforts and shared knowledge. With your videos learning such complex topic is a breeze!
Great !! :-)
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
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! :-)
Your videos and website tutorials are just fantastic! Thanks!
Thanks! :-)
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!
Very good explanation! Good level of depth knowledge about Threads and CPU arch! Congrats again for the great summariazation!
Thank you! :-)
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 ;-)
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
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?
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.
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 ! :-)
Best explanation I have ever seen...
Thank you very much !! :-)
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 .
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.
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.
Dude your explanation is awesome. Thanks for that quality of content. Please keep going
Thanks! :-) ... I will continue - when I have time :-)
Thank you Jacob for this pretty clear explanation , good job
You are welcome! I am glad it was useful :-)
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 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! :-)
Excellent Jakob! Excellent presentation! Thank you!
You are welcome! :-)
Great explanation!
Thanks :-)
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! :-)
Thanks Jakob, these are some amazing videos!
You are welcome! Glad you like them! :-)
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 :-)
Great explanation 👌. Thank you for your work.
You arr welcome :-)
Amazing tutorial. Thank you for your work!
Thanks - and you are welcome! :-)
Thank you Jakob, nice explanation
Glad you liked it ! :-)
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!! :-)
More Java tutorials please! 👍
I will try ! :-)
Good one, quite helpful. Thanks Jakob.
You are welcome :-)
Wonderful tutorials! Thank you a lot!
You're very welcome! :-)
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!
Man that tutorial is amaizing !!!
Thanks! Great to hear! :-)
this is mindblowing, love the vid, thanks
Glad you liked it :-)
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 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 😬
Perfect video. Thank you!
You are welcome! :-)
Good explanation, thank you 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.
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!
Thank you for the video!
You are welcome!
nice tutorial, thank you) Have just one question, is synchronized keyword enough to guarantee atomicity ? Don't we need to use volatile keyword as well to guarantee that the operations are performed directly via RAM?
If you use a synchronized block you do not need to use the volatile keyword around the variables accessed inside the synchronized blocks. The volatile keyword is used to provide some level of thread visibility without having to use synchronized blocks. Thus, volatile is a weaker thread synchronization mechanism, but it offers higher performance than synchronized blocks - e.g. via non-blocking concurrent algorithms and data structures.
Awesome content, so clear!!
Thank you ! :-)
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 RUclips 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
Thanks a lot Jakob!
You are very 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.
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.
Awesome tutorials!
Thank you very much !!! 😊
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!
Jakob, how can you explain that if we set the counter variable as volatile, both results are usually less than 1 000 000.
Even if a shared counter is volatile - the increment operation (counter++) is not atomic. The incrementation does not happen out in the memory where the volatile memory is stored. Two CPUs might load the value of the counter into a CPU register, increment it, and write that value back to the volatile variable. If both CPUs load the value 2 into a local CPU register, both will increment it to 3, and write 3 back to the memory. Even if both variables write the incremented value back to memory immediately, one of the increments will "get lost". Only writes to a volatile variable are atomic. But - an increment is a read-increment-write operation - and is thus not atomic. This is, by the way, what we have atomic operations such as compare-and-swap for. I've made a vide about that too, here:
ruclips.net/video/ufWVK7CHOAk/видео.html
So professional!respect!
Thank you 😊
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.
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.
Hi @Jakob
I watched this video and also read part of the documenation about the volatile. I understood that non-volatile variables does not guaranteed but volatile variables is not enough like you explain in your documentation attached to this video. I also tested the volatile instead of synchronize {} block and faced the race condition. Please, do you see any reason to use volatile modifier if it is not enough to avoid of race condition?
There are situations where you need "thread visibility" - but where the code is written in a way where no "race condition" can occur. The volatile keyword is very helpful in such situations. Look into "non-blocking concurrrent data structures" to learn more :-)
Excellent explanation. Could you share with us images of those diagrams?
Thank you, bro
Nice work!
Thanks - and you are welcome ;-)
21:23 why the count is different for both threads? If the count is shared between threads they should print same values right?
I cover that in the video. If two threads share a member variable, and that member variable is not declared volatile, nor accessed from inside a synchronized block, there is no guarantee about when each thread will read the latest value of that variable from main memory into CPU registers, nor any guarantees about when each thread will commit the latest value of the member variable back to main memory so other threads can see it. Thus, each thread may be working on "stale" local values - not seeing the changes other threads have made to the same member variable.
In the case of a shared count variable which is read-then-incremented, declaring the variable volatile is not enough - because a read-check-change-write operation on the same, shared variable by multiple threads will lead to race conditions. Thus, the read-check-change-write operation must be "atomic" - which can be achieved by performing these operations within a synchronized block (or using e.g. an Atomiclong as counter etc.).
@@JakobJenkov I got it now. The reason why I asked it because I thought both threads exit at the same time.(you didn't mention this in the video). And as they have access to same variable location in memory they should print same value when both exit at same time.(even though count is different due to race condition)
So according to your explanation I understood that there is no guarantee that threads exit at same time.
@@a.yashwanth I think *any* use of the count must use synchronized (or volatile) in order to get the right value. In the code example, the increment to 'count' is synchronized. The System.out is not synchronized, so i presume it uses a value from the Register or Caches?
@@michaelhughes8413 The thread that finishes incrementing first will have incremented the count by a million. At this point the count may not be 2 million yet and it may proceed to create the string that is to be printed out with this < 2 million count. Suppose this evaluation is done, but the scheduler decides to delay the System.out.print I/O call and let the other thread complete the rest of its task. Then you have the other thread incrementing the count to 2 million, creating the string, then printing it out. And finally the first thread prints out the string that now contains the old value of the count.
Even if you synchornized the System.out portion, the thread that finishes first can still print a < 2 million count. The only guarantee is that it will print this < 2 million count before the other thread prints the 2 million count.
Good one, mate
Thank you! :-)
perfect explanation
Thank you :-)
Thanks for your work!
My pleasure! :-)
Thank you so much for the quality video! I just have one question. I recently tried hard to really grasp what the word jvm stands for. But, the word jvm is explained quite differently at different places. Watching your video, it seems like jvm is just a part of physical ram. Am I correct on this?
JVM meand Java Virtual Machine. It is the application (process) that executes your Java application.
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! :-)
Great!
Thanks! :-)
well explained 👏
Thank you :-)
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.
In the separate objects class you have created an my object and you are passing that same object reference to both runnable so it's printing same object. Not because of the object reference is created in the class level in the runnable class . Correct me if I am wrong.. thanks a lot helping us to understand the concepts ...
I am not entirely sure what you mean? The object reference is not what matters. It is the actual object pointed to on the heap that matters.
@@JakobJenkov yes that what I mean. Thanks