The Java Memory Model - The Basics

The Java Memory Model specifies where variables and objects are stored inside the Java virtual machine, as well as how Java Threads access and share these variables and objects. This Java Memory Model tutorial explains the basics of the Java memory model.
Two concepts are left out of this tutorial: The Java synchronized and volatile keywords. Each of these keywords are explained in their own tutorials (see links below).
Chapters
0:00 Introduction to Java memory organzation - AKA the Java Memory Model
0:29 Java Thread stacks and the heap
1:10 Location of local variables and objects
2:52 Code examples of local variable and object locations
10:45 The thread stacks and heap mapped onto a hardware architecture
12:13 How variables and objects move through the RAM, caches and CPU registers
13:19 How the memory organization in Java can lead to race conditions
15:15 Data update visibility between threads
16:35 Cache coherence strategies do not guarantee data update visibility
18:19 Demo of race conditions in Java threads.
Java Memory Model - JSR 133
www.cs.umd.edu/~pugh/java/mem...
Java Memory Model tutorial - text:
tutorials.jenkov.com/java-conc...
Java Concurrency playlist:
• Java Concurrency and M...
Java synchronized keyword tutorial:
tutorials.jenkov.com/java-conc...
Java volatile keyword tutorial:
tutorials.jenkov.com/java-conc...

[@JakobJenkov]

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: kzbin.info/www/bejne/pYqUZYivhZtkfJo

[@amalangelraj]

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.

[@Shivam-wk6sq]

One of the best tutorials out there.. This is literally a goldmine.. Thanks a lot

[@JakobJenkov]

Thank you very much !! 😊

[@kamranvlizad3862]

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.

[@JakobJenkov]

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 :-)

[@fuadgafarov]

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)

[@JakobJenkov]

Thank you very much - glad my video helped you :-)

[@prakritidevverma4315]

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. 😬

[@JakobJenkov]

You are welcome!! :-)

[@user-sp7kp9mo1q]

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

[@JakobJenkov]

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 ;-)

[@jayasribhattacharya2048]

you deserve more subs. your vids are awesome.

[@JakobJenkov]

Thank you very much :-)

[@MrPersistent16]

Agreed!

[@RoadRoller01]

Agreed! !

[@shubhamagarwal1434]

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]

Thank you for your kind words ! :-)

[@mondofps]

Your tutorials are absolutely fantastic and have taught me so much, thank you.

[@JakobJenkov]

I am happy to hear that :-)

[@bharatjain90]

Your videos on multithreading are the best explanation I have come across in 20 years of java exp.

[@JakobJenkov]

Thank you very much for your kind words! :-) Glad the tutorials are helpful!

[@RC_1930]

I'm preparing for the OCA exam, and this was exactly what I needed. I thank you Jakob from the bottom of my heart.

[@JakobJenkov]

You are welcome! ... remember to also watch Part 2 about the Java Memory Model - the Happens Before Guarantee video!

[@manOfPlanetEarth]

@@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.

[@eduardojavierlatorrevandep4583]

I really appreciate all the details you give out in your tutorials! I've been learning so much with you... keep it up :)

[@JakobJenkov]

I am happy to hear that! :-)

[@nabeelahs9588]

So happy to see you have a channel. I've been using your tutorials online and they're awesome.

[@JakobJenkov]

Thank you very much! I am happy you found my channel then! :-)

[@mostinho7]

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

[@manOfPlanetEarth]

nice addition.

[@isahilliogluu]

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.

[@JakobJenkov]

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.

[@michaeldemarco82]

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"

[@JakobJenkov]

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!

[@lewallen1971]

Your videos and website tutorials are just fantastic! Thanks!

[@JakobJenkov]

Thanks! :-)

[@roman_mf]

Thank you Jakob for all your efforts and shared knowledge. With your videos learning such complex topic is a breeze!

[@JakobJenkov]

Great !! :-)

[@alexs9289]

Awesome videos, as other people stated. Keep them coming, your work really helped me understand concepts that other teachers couldn't explain !

[@JakobJenkov]

Thanks - will try :-) ... which teachers?

[@hongzhanglin6245]

thanks you Jakob, I hadnt see tutorials like yours ever. your tutorials are simple and easy to understood, i like it.

[@JakobJenkov]

Thank you very much !! :-)

[@reynaldolibutan8468]

this tutorial and how you slowly present your ideas with examples is too underrated! You need more subs, views and exposure in general!

[@JakobJenkov]

Thank you Reynaldo :-)

[@snoz9048]

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]

Thank you very much for your kind words! I appreciate that! And - I am happy that you find my videos useful :-)

[@aelkelaany]

Thank you Jacob for this pretty clear explanation , good job

[@JakobJenkov]

You are welcome! I am glad it was useful :-)

[@michaelhughes8413]

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!

[@JakobJenkov]

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!

[@hstanciu]

Excellent Jakob! Excellent presentation! Thank you!

[@JakobJenkov]

You are welcome! :-)

[@bahaagamal4995]

You are very good in arranging and describing the information. Very nice video.

[@JakobJenkov]

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.

[@theunusual4566]

Thank you so much Jakob for creating such wonderful videos and presenting them in so easy to understand way.

[@JakobJenkov]

You are very welcome :-) Glad my videos help you! :-)

[@MarceloAX]

Very good explanation! Good level of depth knowledge about Threads and CPU arch! Congrats again for the great summariazation!

[@JakobJenkov]

Thank you! :-)

[@matthewsaucedo2471]

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!

[@JakobJenkov]

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 :-/

[@FABGIO1]

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!

[@JakobJenkov]

I am happy to hear that!!! ... you are very welcome! :-)

[@tomok284]

Few tutorials will link it to the hardware. You are doing a great job!

[@JakobJenkov]

Thanks !

[@mtqin2956]

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 +

[@JakobJenkov]

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!

[@andrewshatnyy]

Amazing tutorial. Thank you for your work!

[@JakobJenkov]

Thanks - and you are welcome! :-)

[@sergiomatiash5977]

Dude your explanation is awesome. Thanks for that quality of content. Please keep going

[@JakobJenkov]

Thanks! :-) ... I will continue - when I have time :-)

[@evgenyleshok5892]

Thank you very much! Your explanation and examples are really helpful. I wish you the best and motivation to create more such good content!

[@JakobJenkov]

Thank you very much ! :-)

[@rohitk9221]

This is the best explanation for threads on the internet and even in the libraries of the entire world!

[@JakobJenkov]

Thank you very much :-) ... remember to also watch my follow-up video "The Happens Before Guarantee" - to fully understand the Java memory model !

[@ankuraagarwal]

Good one, quite helpful. Thanks Jakob.

[@JakobJenkov]

You are welcome :-)

[@ashutoshkedar1577]

You are the most amazing tutor I have ever had. Kudos to your teaching skills.

[@JakobJenkov]

Thank you very much! :-D

[@samuel2560]

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!

[@JakobJenkov]

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 :-)

[@manOfPlanetEarth]

@@JakobJenkov Denmark! aaaah, you're not english native:)) i guessed that while reading articles on your site. Very often very bad sentences structure:)

[@gloriafigueroa8129]

Thanks Jakob, these are some amazing videos!

[@JakobJenkov]

You are welcome! Glad you like them! :-)

[@AbhishekVaid]

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.

[@AnkitKumar-zu7cn]

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).

[@JakobJenkov]

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.

[@ohadlevy5719]

Thank you very much for the videos. they make the subject easy to understand. Keep it up and once again thank you :).

[@JakobJenkov]

Thank you for your feedback! ... I have many more videos planned - it's mostly a question of getting the time to record them :-)

[@aaronrasing2710]

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.

[@JakobJenkov]

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.

[@kzelmer]

Best explanation of Java concurrency hands down. Thank you Jakob

[@JakobJenkov]

Thanks ! :-)

[@ripusudan100]

jakob i follows you from starting of my career...your tutorials are clear and well explained!!!

[@JakobJenkov]

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

[@AvinashKumar-tk5bd]

Guruji @jakobJenkov no words to describe.you made this complicated topic very easy.Thank you saw muchhhh

[@JakobJenkov]

Thank you very much! :-) I am happy my video has helped you!! :-)

[@guptatushar86]

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 !

[@JakobJenkov]

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.

[@ky747r0]

Great explanation!

[@JakobJenkov]

Thanks :-)

[@Ketrixx]

Man that tutorial is amaizing !!!

[@JakobJenkov]

Thanks! Great to hear! :-)

[@user-kz4jr9ti4x]

Thank you Jakob, nice explanation

[@JakobJenkov]

Glad you liked it ! :-)

[@garimadhanania1853]

Awesome content, so clear!!

[@JakobJenkov]

Thank you ! :-)

[@Shonia]

Wonderful tutorials! Thank you a lot!

[@JakobJenkov]

You're very welcome! :-)

[@thomasrixen5390]

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

[@JakobJenkov]

I am not sure if that is a good thing - or a bad thing ;-)

[@MeftahLakehal]

Good explanation, thank you Jakob!

[@JakobJenkov]

You are welcome ! :-)

[@magdak1556]

Perfect video. Thank you!

[@JakobJenkov]

You are welcome! :-)

[@anmolsandal3454]

Great explanation 👌. Thank you for your work.

[@JakobJenkov]

You arr welcome :-)

[@SoeaOu]

this is mindblowing, love the vid, thanks

[@JakobJenkov]

Glad you liked it :-)

[@ritwikkumar1402]

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

[@JakobJenkov]

Thank you very much for your kind words! :-)

[@paulisaichuk5034]

Thank you for the video!

[@JakobJenkov]

You are welcome!

[@xixia1597]

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.

[@JakobJenkov]

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 .

[@jvsnyc]

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.

[@JakobJenkov]

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!

[@marmont8005]

Thank you, bro Nice work!

[@JakobJenkov]

Thanks - and you are welcome ;-)

[@trdngy8230]

Thanks for your work!

[@JakobJenkov]

My pleasure! :-)

[@billwu7367]

So professional!respect!

[@JakobJenkov]

Thank you 😊

[@mehtubbhai9709]

More Java tutorials please! 👍

[@JakobJenkov]

I will try ! :-)

[@shreyasgosavi9647]

Woww!!! That was a very good explanation .. learned a lot in a single !! video over to the next one ;)

[@JakobJenkov]

I am happy to hear that! :-)

[@osamabassam7517]

Amazing explanation.

[@JakobJenkov]

Thanks :-)

[@jgwhite5728]

Awesome tutorials!

[@JakobJenkov]

Thank you very much !!! 😊

[@flamencoag]

Thanks a lot Jakob!

[@JakobJenkov]

You are very welcome :-)

[@rishabgoyal6138]

This really good content low level java understanding with coverage of multithreading.

[@JakobJenkov]

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!

[@bayraminanc885]

perfect explanation

[@JakobJenkov]

Thank you :-)

[@jatinsinghal9486]

You explanation is awesome. I want to be like you one day

[@JakobJenkov]

:-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!

[@jericho7989]

well explained 👏

[@JakobJenkov]

Thank you :-)

[@MrVipulLal]

Good one, mate

[@JakobJenkov]

Thank you! :-)

[@RobbieBobbie107]

this is a great video thank you

[@JakobJenkov]

You are welcome! Glad you liked it! :-)

[@maksymmatlo4327]

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!

[@JakobJenkov]

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.

[@khomo12]

Great!

[@JakobJenkov]

Thanks! :-)

[@manOfPlanetEarth]

nice, nice lesson. read a few lessons in text, now am covering them with video. can notice video is more detailed.

[@JakobJenkov]

Thank you! Great to hear! :-)

[@manOfPlanetEarth]

@@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.

[@hliebhalunko5214]

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 :)

[@JakobJenkov]

Concurrency will get you puzzled from time to time in any case :-D ... still happens to me too sometimes ;-)

[@ASTATEPACH]

I think it's because Threads have a nondeterministic behavior in where external/internal conditions could affect the way your thread produces.

[@abenezertilahun610]

Thank you

[@JakobJenkov]

Welcome!

[@justinf1343]

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

[@JakobJenkov]

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.

[@justinf1343]

@@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 😬

[@lbirowka]

Excellent explanation. Could you share with us images of those diagrams?

[@nopepsineedcola8893]

so good

[@JakobJenkov]

Thanks :-)

[@timurkhasanov5978]

thanks!

[@JakobJenkov]

Welcome! :-)

[@user-pc5xz9oj6c]

you are the best

[@JakobJenkov]

Thanks :-D

[@ManishKumar-qx1kh]

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.

[@JakobJenkov]

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.

[@jasper5016]

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.

[@JakobJenkov]

Hi Jasper, I am glad my tutorials are helpful for you! :-) ... I don't have any courses on Udemy, Pluralsight, LinkedIn Learning ... only KZbin and Odysee, and my website jenkov.com so far :-)

[@jasper5016]

@@JakobJenkov Thanks!

[@srinivastadinada4846]

Hidden gem..

[@JakobJenkov]

Thanks :-)

[@minasalah8210]

thank's...

[@JakobJenkov]

You are welcome !! :-)

[@Anonimus_13]

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?

[@JakobJenkov]

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.

[@qwlol]

I wish I could give you more likes

[@JakobJenkov]

:-D ... well, I appreciate every like my videos get - even if just one at a time ;-)

[@vikrantkaushal9650]

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?

[@JakobJenkov]

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.

[@vikrantkaushal9650]

@@JakobJenkov oops my bad. Hats off sir. Your videos are really good. Thanks a lot

[@alexandreabarbosa]

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?

[@JakobJenkov]

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 :-)

[@szalkowm]

10/10

[@JakobJenkov]

Thanks :-)

[@woosukbyun2455]

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?

[@JakobJenkov]

JVM meand Java Virtual Machine. It is the application (process) that executes your Java application.

[@marcin83kra]

Jakob, how can you explain that if we set the counter variable as volatile, both results are usually less than 1 000 000.

[@JakobJenkov]

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: kzbin.info/www/bejne/q5e6h35teK2Cd80

[@bhanuchirutha]

Nice, I have read ur link about JAVA IO did you also do a video about it?

[@JakobJenkov]

I have not yet made any videos about Java IO, but I might do that at some point. They will be findable via my KZbin channel or tutorial website when I do!

[@bhanuchirutha]

@@JakobJenkov wow thank you

[@123iamnoob]

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 :)

[@JakobJenkov]

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.

[@lytung1532]

The video is useful. Could you explain why race conditions also happen in case of single CPU?

[@JakobJenkov]

Race conditions can happen on a single CPU because two threads may read-check-then-act on the same variables at almost the same time - e.g. like this: T1: read count into CPU register (count = 1) T2: read count into CPU register (count = 1) T1: set count = count + 1 (count = 1 + 1 = 2) in CPU register - not main memory T2: set count = count + 1 (count = 1 + 1 = 2) in CPU register - not main memory T1: write count from CPU register to main memory T2: write count from CPU register to main memory Even if executed on the same CPU, it can switch between the threads in a way where T1 does not see the updated count value of T2 - because the value of count is stored internally in the T1 thread context until finally written back to main memory. How exactly this works depends on the OS, CPU, hardware etc. but it can happen. Most CPUs these days have a least 2 cores - so race conditions are more likely to happen than ever.

[@lytung1532]

@@JakobJenkov Thank for super fast reply. I got it now.

[@AbhishekVaid]

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 ?

[@JakobJenkov]

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.