Java Volatile

The Java volatile keyword can be applied to Java variable declarations to force the Java VM to always read the variable value directly from main memory, and always write changes to the variable directly back to main memory immediately.
Chapters
0:00 Java volatile introduction
0:41 Non-volatile variable visibility problems
2:27 Java volatile visibility guarantee
5:30 Instruction reordering could break the Java volatile visibility guarantee
12:33 Java volatile happens before guarantee
15:03 Java volatile performance overhead
15:56 Java volatile is not always enough
Java Memory Model - JSR 133
www.cs.umd.edu/~pugh/java/mem...
Java volatile tutorial - textual:
tutorials.jenkov.com/java-conc...
Java synchronized tutorial - textual / video:
tutorials.jenkov.com/java-conc...
• Java Synchronized - Th...
Java concurrency tutorial - textual:
tutorials.jenkov.com/java-conc...
Java concurrency tutorial - playlist:
• Java Concurrency and M...

[@user-rc8rv4sk2j]

The favorite part of this series of videos are those clear diagrams. They make the internal things clear and comprehensive.

[@JakobJenkov]

I am happy you like those diagrams! It actually takes me some time to figure out how to illustrate the points in the clearest way.

[@omnipoten8]

Again, the best explanation I have ever seen about volatile keyword in Java. As clear and concise as it can be . No loopholes, no smart fancy tech words to confuse the meaning, but just a clear cut explanation. I have infact wrote down the key sentences from this video in my notes :) . Once again you nailed it Jakob !

[@JakobJenkov]

Hi Vishal, I am happy you feel that way :-) ... I've had my share of hard time trying to understand many advanced concepts - often because the descriptions were hard to understand.

[@sujeetbadnale9441]

Thank you@@JakobJenkov, for making saving us from the hardships that you have gone through. Indeed you are blessed and now are being blessing for us. God Bless You. Continue to be a blessing for all of us.👼

[@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]

Thanks :-)

[@repotek]

That was super clear. As long as you deliver this concept very smoothly, then you understand it very well. which is very rare this days.

[@JakobJenkov]

Great to hear it was clear !! That's what I am trying to do - to make sure each video presents its topic as clearly as possible 😊

[@Abdullahkhan-ks2py]

Thank you so much for this video. I was always confused with volatile and this video has cleared all my doubts. True java champion!! Thanks

[@JakobJenkov]

Thank you very much !! 😊

[@ajaygaulia1767]

Awesome demonstration and explanation Jakob!! Loved it!! keep up the good work!!

[@JakobJenkov]

Thank you ! ... I will try to make more videos soon! :-)

[@VLADICA94KG]

Thank you so much for such a concise and clear presentation! Please keep uploading such a great content!

[@JakobJenkov]

You are welcome ! :-)

[@farhadpagdiwala4458]

Another very cool and informative video on Java volatile keyword functionality. Thank you so much for making and posting this video!!

[@JakobJenkov]

You are welcome :-)

[@user-hg2pf1hs4z]

I always love your style to make all of things really simple

[@JakobJenkov]

Thank you very much! :-) ... I do try hard to make the topics easy to understand! :-)

[@jkwong6167]

Brilliant explanation with simple and easy to understand examples. Thanks a lot!

[@JakobJenkov]

You are welcome! ... and thank you for taking the time to tell me! :-)

[@susanwowe7810]

Nice Explanations with a calm tone. Thank you.

[@JakobJenkov]

You are welcome! :-)

[@alexwhb122]

This is an awesome video! Thank you so much for your detailed explanation. by far the clearest explanation I've seen on this topic.

[@JakobJenkov]

Thank you very much :-)

[@joeyzhao1596]

Clear explanations and perfect examples. Thx.

[@JakobJenkov]

You are welcome! Glad it helped! :-)

[@nitinpandey2859]

Nicely explained, very helpful video. Thank you Jakob.

[@JakobJenkov]

You are welcome! Glad you found it informative :-)

[@theunusual4566]

Another Superb Video with wonderful knowledge shared in detailed way. Thank you so much Jakob :)

[@JakobJenkov]

Thank you very much! :-) ... and you are welcome! :-)

[@crazy-boy6143]

I hit the like button and subscribed, so I hope new videos will come out before I finish those 22 videos. Thanks for those awesome videos, I really appreciate it

[@JakobJenkov]

Hi ... I wish I had a whole lot more time to make KZbin videos :-) ... but my time is a bit limited these days. I still plan to release videos on a continual basis - but christmas and new years was pretty busy for me!

[@ffatheranderson]

Jakob :) you've decided to start videos. :) Thank you. I like your blog about java, read about 3 articles. Wish you luck!

[@JakobJenkov]

Thank you ... but you should wish me "time" more than luck :-D

[@hectorrios1432]

I agree with the other comments. Very clear and simple explanation. Thank you!

[@JakobJenkov]

Thank you very much, Hector :-)

[@rohalkurup3063]

Thanks Jakob for the wonderful explanation .. :)

[@JakobJenkov]

You are welcome! ... and thank you for letting me know :-)

[@SosetaFurioasaJr]

I liked how you presented, thank you.

[@JakobJenkov]

Thanks - glad you liked it :-)

[@IdeeFixeGamer]

Great tutorial really useful, super underrated channel.

[@JakobJenkov]

Much appreciated! :-)

[@gtian8669]

very clear explanation! thank you so much!

[@JakobJenkov]

Your are welcome :-) Glad you found it helpful!

[@oleksandr3275]

Super cool explanations, thank you so much 👍

[@JakobJenkov]

You are very welcome ! :-)

[@BD-mc7lc]

Thank you! Every good explanation

[@JakobJenkov]

You are welcome ! :-)

[@fannyfan1742]

thanks for this very clear explanation. SUBSCRIBED

[@JakobJenkov]

You are welcome! :-)

[@nikkipik3411]

Man , ur awesome , such great explaination , loved it.

[@JakobJenkov]

Thanks - glad you liked it! :-)

[@gparashar4u]

Great explanation.

[@JakobJenkov]

Thanks - glad you think so! :-)

[@romanburenko7593]

great explanation!

[@JakobJenkov]

Thank you! :-)

[@SoeaOu]

excellent tutorials, thanks

[@JakobJenkov]

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

[@lifesport1380]

Very nice, continue going on🔥

[@JakobJenkov]

Thank you! :-)

[@husohomeful]

you deserve more views.

[@JakobJenkov]

Thank you ! .... then I better make some more videos 😉

[@user-sb4jr9rg4q]

Good explanation thank you

[@JakobJenkov]

Thank you 😊

[@jonneyjonney8942]

Awesome 👌

[@JakobJenkov]

Thank you :-)

[@AtiqurRahman-gj6mg]

Best explanation

[@JakobJenkov]

Thanks :-)

[@garimadhanania1853]

thank you! 😃

[@JakobJenkov]

You're welcome 😊

[@Khrystyable]

Thank you, Jakob! But I have a question. Is it make sense to mark two or more variables as volatile in one class?

[@JakobJenkov]

That depends on how you access these two variables from different threads. If they are accessed separately, then yes. If they are always accessed together, first A then B, then it probably doesn't make as much sense.

[@MahfuzurRahman-xl9pj]

@@JakobJenkov I have follow up question. Suppose variable A and B are access together by a thread and made both the variables volatile, is there any performance overhead?

[@vincool5507]

Great video and nicely explained. One question though : When you say " all variables visible to thread at the time of volatile read/write" , When is a variable considered VISIBLE to a thread.

[@JakobJenkov]

You are welcome :-) Regarding your question - I have myself been looking for the exact definition of what "variables visible to a thread" means - but I have not yet found a 100% precise definition. I assume that it at least means all variables accessed from within a given synchronized block, or inside a method that accesses a volatile variable. Possibly all member variables within the current class. Possibly even variables further up the call stack.

[@manOfPlanetEarth]

@@JakobJenkov For myself I supposed all vars within visibility scope at the spot of "happening" (deals with volatile vars/synchronized blocks).

[@jayeshghule1]

@@JakobJenkovI appreciate the explanation, but honestly I did'nt understood what visible variables to the thread means , if we are not sure what "variable visible to thread" specifically means, then how can you suggest that don't use volatile for two variables that are together, or moved outside and up to the synchronized block. Ideally the best practice is to make all of them volatile when we expect guaranteed visibility because we never know what will happen for sure.

[@ehabahmedyassen]

Hi Jakob, thank you so much for the amazing concurrency tutorial :) I have learned a lot from your course till now and still have about 17 lectures to go. I have a question/suggestion about the given example in this lecture. As I understand, Thread-1 is meant to execute the setter method and demonstrate the benefit of having the volatile variable "int val3" being written to at the end of the method "final instruction" and that this will force the program to write the other 2 variables to the main memory as well as val3. However, i think this example is mixing things a bit because in the setValues method, we are reading values in a different order from the order suggested in the getValues method. I'd like to know how do you see it from this point of view. Thanks in advance :)

[@JakobJenkov]

The order should be reverse in the get and set methods.

[@SahilRallySuperStar]

Best !

[@JakobJenkov]

Thanks :-)

[@alienmatrix235]

Great video! I have a question about non volatile variables being flushed to/ read from when a volatile variable is read / written to. Is this a side effect of the size of the CPUs cache lines? Or does the JVM specifically guarantee that all visible variables will be read from / flush to main memory? For example, say we have 64 byte cache lines, but a class has 100 fields (more than what would fit into a single cache line). If the 100th field is volatile and I write to it, will all 100 fields be flushed to main memory? Or only the n closest fields that can fit in the cache line?

[@JakobJenkov]

That's a very good question! I have only been able to find a description saying that "all variables *visible* to the thread are flushed..." , but I have not been able to find a precise definition of what "visible" means, unfortunately. Is it only the variables accessible from inside the method that accesses the volatile variable? Or does it also include member variables / static variables inside the class contaning the method? And what about variables "visible" further up the call stack of the same thread? To be on the safe side, I consider "visibility" to be narrow - meaning parameters and local variables of the method accessing the volatile variable + member variables in the same class. Questions like these is why I prefer a single-threaded / same-threaded concurrency model - similar to what is used in Node.JS . I will be making a video about this type of concurrency model soon. Then you have a lot less concurrency issues to deal with.

[@rajasekharb7901]

@@JakobJenkov Hi Jakob, Did you get the answers for your questions or still waiting!.. because I also want to know your question's answers.

[@manOfPlanetEarth]

@@JakobJenkov Hello! Have you done mentioned video about same-threaded concurrency approach/model?

[@minasalah8210]

thank you.

[@JakobJenkov]

You're welcome !

[@rishavmasih9450]

Hey JakoB great video, as always. A suggestion, I would highly apprecite if you could link the source material.

[@JakobJenkov]

Many of my Java code examples can be found in this GitHub repository github.com/jjenkov/java-examples

[@rishavmasih9450]

@@JakobJenkov Thank you. Are there any books that you refer to, before making theses videos.

[@iwebappe7981]

Thanks for the video, I got a question please When you say, threads will read variables from the main memory, you mean from the JVM heap right? this sounds logic for reference type objects where the objects inside the threads stacks will point to the JVM heap so if you modify the object inside the heap, the references inside stacks will point to the new object but for primitive types, values are directly stored inside stacks, there's no track of them inside the heap so how come you speak about Main memory in this case? does this mean that when we declare a primitive variable as volatile it will be stored in the heap instead of each thread stack? I appreciate it a lot if you could explain this point

[@JakobJenkov]

No - by "main memory" I mean RAM. Both the thread stacks and the heap are kept in RAM - and then replicated up through the L3, L2 and L1 caches on their way to the CPU registers - when used. The concepts of the [CPU registers, L1, L2, L3 caches] and the [Thread stacks + Java VM Heap] are orthogonal concepts.

[@bunthaideng2492]

Really appreciate your tutorial. seems the volatile is not for thread-safe, is it a better to use the synchronized (read/write) rather than the volatile?

[@JakobJenkov]

It depends on the situation. If you just need other threads to be able to read what one thread writes, then in some cases it is enough with volatile... but it depends.

[@AllInOne-jg5qx]

That was the good Explanation. But the thing is you should have also written the programs and executed them for better understanding. I can understand that your video was being too long. But there should be a part 2 of this video...

[@JakobJenkov]

You should write the programs - as an exercise ;-)

[@bhumikasingh850]

How to make sure that a piece of code is executed by a single thread across multiple JVM instances (app deployed on multiple servers)?

[@JakobJenkov]

That is a much harder task. Some early implementations used a database lock in a database shared by all the JVMs. You would probably have to use something similar to that.

[@user-uc5iv5gf5u]

I've got a question to a diagram on 13:30. Does having only val3 as volatile variable (not all three) guarantees the stableness of visibility rule? I mean, the thread interruption may happen after the assignment of this.val2 in setValues method (because no synchronized keyword here). In this case, getValues will read incorrect values from main memory because the changes weren't pushed to main memory (because thread interruption occured before assignment to volatile variable). Correct me, if I'm wrong

[@JakobJenkov]

If the thread interruption happens after assignment of val2, not thread visibility is guaranteed. What I am saying is - that once val3 has been set, the fact that val3 is volatile means that thread visibility also kicks in for val2 and val1 too.

[@sureshkct]

Please post the continuous video java. at least week ones ....

[@JakobJenkov]

I will try to post as often as I can! ... but it's sometimes hard to find the time after work :-) But I will try!

[@adil-hussain-84]

In the first example, why is the 'object' property not marked as 'volatile' also? In the absence of the 'volatile' keyword, do we not run the risk of referencing a stale object on line 17?

[@adil-hussain-84]

My bad. The video answers my question at the 3-minute mark.

[@JakobJenkov]

Great :-)

[@islombekmamatqulov7821]

perfecto

[@JakobJenkov]

Thanks :-)

[@danishrockz1]

so If our Threads run parallelly then using volatile won't help.. since exact same time thread might be accessing same volatile var

[@JakobJenkov]

If both threads read and write the same volatile variable - they have to be quite careful to avoid race conditions - yes. However, if one thread only writes to the volatile variable, and the other thread only reads it - then it will work. This situation is also known as single-writer-single-reader - or - single-reader-single-writer .

[@manOfPlanetEarth]

@@JakobJenkov many threads can write volatile at the same moment. Note: if it is "one touch" writing: you do not need firstly read then modify it then write, a thread just puts his value and runs away:) It's ok for volatile.

[@ultimatewarriorfrieza275]

I declared a class with a volatile boolean variable with an initial value of true. Created 4 threads which run 3 statements Print the variable Change it to false And print again When I started the 4 threads, I expect 8 lines of output and that whenever i see a false appear for the first time, the next statements must follow suit. But that isn't the case with my results. How was that happening?

[@JakobJenkov]

Do all threads share the same instance of that class you created? Or do they have each their own instance of that class? Only if the instance is shared between all threads will you get the expected behaviour.

[@ultimatewarriorfrieza275]

@@JakobJenkov it does, all threads run through this variable. I tried it and I expected that the first time I see false all the remaining statements should return false but it has not.

[@ultimatewarriorfrieza275]

@@JakobJenkov public class Sample{ public static void main(String... args){ A a = new A() ; Runnable r = new Runnable() { public void run() { System.out.println(a.flag); a.flag=false; System.out.println(a.flag); } } ; Thread t1 = new Thread(r); Thread t2 = new Thread(r); Thread t3 = new Thread(r); Thread t4 = new Thread(r); t1.start(); t2.start(); t3.start(); t4.start(); } } class A{ volatile boolean flag = true; }

[@sihanadi5149]

I really don't understand what's the problem of count at the end of video

[@loki549]

Thank you! And I also want to ask you to talk a bit more clearly, because I'm not a native speaker, and sometimes it's hard to understand you.

[@JakobJenkov]

I am also not a native English speaker. I am already trying to speak as clearly as I can - so I am not sure I can do any better without speaking incredibly slowly. But - there are already others complaining that I speak too slowly, so I will probably not slow too much down.

[@loki549]

@@JakobJenkovOh It's Ok bro, you're doing a great job, Thanks 👍

[@emil8367]

setVal does getVal and getVal does setVal, hmm interesting if you know what I mean :-)

[@smithcodes1243]

yeah what's going on there

[@-boiadeiro-]

so much overhead w volatile ffs..

[@JakobJenkov]

volatile ffs?

[@smithcodes1243]

@@JakobJenkov ffs = for fuck's sake, he is basically annoyed with how much extra work and things we have to consider when using volatile keyword in java.