in this video, we will have a look at how Java treats access memory and how the memory is organized inside the Java virtual machine with relation to threats. To explain how memory is organized and accessed inside of the Java VM, I will be using mostly diagrams, but I also have a few code examples to help illustrate the points made in the diagrams. If you look at the diagram here on the right, you can see that it contains two threats. Each threat has a threat stack. A threat stack is an area which can only be accessed by the threat that owns the thread stack. So the left thread can only access the left thread stack, and the right thread can only access the right thread stack. And if there were more threats, each threat would have its own thread stack. Then we have the heap down here at the bottom, which can be accessed by all threats. So in case you need to share data between threats, it has to be shared via the heap. You cannot share data between threats via the thread stacks. On the thread stack, all the local

variables are stored. For instance, these two variables here are local because they are defined inside of a method. They are local to this method. They can only be accessed from inside of the main method. So, the myLocal variable here, the int, is stored on the stack here, and the reference to this string object here is also stored on the thread stack. Now, the string object itself, however, is stored on the heap. So, that means that in order to represent this string variable here, we both have a reference, which is stored on the thread stack, and we have the string object itself, which is stored on the heap. If two threads were to reference the same object on the heap, they would do so using each their own reference. So, this left thread here would have its own reference here located on its own thread stack, which would reference this object down here on the heap. Now, in case this thread would like this reference here to reference another object, for instance, this one over here, it would be free to choose to reference another object and this one or another one without affecting that the other thread.

reference here would still be referencing this old object here. So the references can reference the same object, but they can also be modified independently of each other to reference different objects. Before we move on, let me quickly re-explain this, but based on a code example instead, so you can connect what I have told you in the diagrams to some actual code. And if you look at the code example here on the Left, I have created to run apples here, and each runnable epi' is passed to a different thread. And that means that each thread does have its own runnable object. So over here on the heap, there will be one runnable object for this thread and another runnable object for this thread over here. Now let's jump into the my runnable implementation so we can discuss a little bit the location of variables in here. If we first look at this local variable here, I then each thread will create its own copy of I because it's a local variable. So this thread here will create an eye on its own thread stack, and this thread over

here will create an eye over here on its own thread state, and that is true even if we have two different variables, but it would also be true even if they share the same runnable. I will show you later in a later example. So, local variables are never shared between threads, okay. However, however, look at this filled in the council that's a member field. It belongs to the my runnable object, so there will be one count field in each runnable, and in this case where each thread gets his own runnable, that means that each state has its own count field also, right, because each runnable has its own count field. However, if we look at this example here where we create only one runnable and we pass it to two different threats, then if we go back into the my runnable, then all of a sudden what is now true is that the I variable here will still be created in two copies, one in each thread stack because local variables are not shared between the threads, but now all of a sudden the count field here that they are accessing because it's the same my

runnable object they are accessing. The two threads then all of a sudden it will be the same count field that they are accessing, and that is because now there's only one my runnable object here on the heap. Both threads are accessing that, and that means there's only a single count field, and that field is then shared between there the threats. If a thread creates an object, for instance, inside their run method here, then each threat that executes the run method will end up instantiating a new object, and each since each object or each threat will actually create its own local variable, then each local variable here will also be assigned to a different object. So that means that over here the my object local variable will be created one in this thread stack and one in this thread stack, and they will point to one new myopia created for each thread because each thread executing this run method will also execute the new my object here. So these instances will not be shared between the threads. In this case here where we have even if we have two different

runnable, but also in case we have one runnable here, like we have a shared runnable, right? But it doesn't matter because each thread will execute this and will thus create two different objects. If we try to run this code example, we can see that this is true. Let me just try to print out my object instance here, and let me first run this example here where we have one my runnable so it's shared between the threads, and you will see that even if we share the runnable, the two threads still create different my object instances. As you can see here, the numbers here means that these two my object instances are different even if we share the same runnable, right? And the same would be, don't mind these numbers, I will explain them later in the video. The same is true if I run this other example here where we are actually using two different runnables, but you can see they also create two different my object instances because these numbers are different. Let me just show you how it would look if we

had shared there my object instance between the two threads. Let's first modify this my runnable class so now it can take and my objects in the instance. Let's do like this. It can take a myopic instance as a parameter to its constructor, right? And then instead of down here creating a new my object, we simply print the field here. And if we get and my object as a parameter to the constructor, we store that as a field. And because it is a field now stored in a field, then it can be shared between the threads, right? Instead of here where it was a local variable. So it was not shared between the threads. Let's have a look at how this looks now. We also need to create and you new my object, and we pass it now to to the constructor here. Now even if these two runnable are different objects so each thread has a different runnable, the runnable internally reference the exact same my object instance. And therefore when we run this example, you will see that now they still print out the same number. Now you can see this number here.

is exactly the same number as down here because now they are referencing the same shared my object instance which is located on the heap right. So we have actually two different run apples, each of them has a my object field internally. So another runnable here but both of these to run apples are referencing the same my object instance on the heap right, the same my object instance on the heap. And even in this case here with it will be the same, we will create a my object instance here right and we pass it as parameter. Now obviously because we only have one runnable now which is yet between two threads and this round will only has one myopic instance day it will these threats will also now be sharing the same my object instance. It is even more obvious right but let me just show you just so that you can see that it is true now look at these numbers here they are the same because these two threats that are started up now share the same runnable instance and the same my object instance now let's have a look at how

this Java memory organization looks when we map it on to a hardware architecture, and of course, hardware architectures are different so this is a bit of a generic architecture that I'm showing you here. You can see we have two CPUs, and it could be CPU cores, or it could be like real separate CPUs, and there could be more than two. Now on this diagram, I just have shown you two, and as you can see the thread code runs on the CPU, and here's another thread that runs on a different CPU. In fact, it is possible for multiple threads to run on the same CPU, but it is better mentally to think about to imagine that the threads are running on different CPUs. Then each CPU has some registers here, which is data storage air that can is local to the CPU, and then it has, we have an l1, l2, and l3 caches, which are fast caches memory cases which are close to the CPU, and then we have the big random access memory down here, the biggest shared memory area here. And in the RAM, we have the fetch stack and the

heap store so actually we have the thread stacks of both of these threads start down here in the RAM. When a threat needs some data either from its threat stack or from the heap, so either local variable or an object reference by a local variable or referenced from another object, it has to access this variables or this these objects through the RAM. Now what the hardware architecture will do is it will copy this information, this data, to the caches here and then eventually possibly to the CPU registers. So, sometimes it will only end up in the cache here and it will be processed here, and sometimes it goes all the way to the CPU registers. This depends a little bit on the Java Virtual Machine and what instructions you are executing, etc. So, but this process here is always the same: the data has to be loaded from RAM into the caches and into the registers. That is the direction of it. And the same way when the CPU if it changes some of the data, then the data has to go the same way back. It has to go from the register

to the cache, and then back down to the RAM again. This organization of memory between the CPUs and the cache is here, and the RAM poses some problems that we need to take into consideration when designing while two-threaded applications in Java. And one of these problems is race conditions. So, race conditions occur when two threads share this share some data on the heap, and they both read and write it, and they do not do so in a synchronized fashion. Let me just explain how the problem can occur. Imagine we have this object here. It has a field called count. The value is 1. Now, thread 1 copies this value up into its CPU registers because it intends to increment the value by 1, so it will be 2, right? And the second thread also wants to increment the value by 1, so it will be well if they did it sequentially, it would be 3, right? It would first be 2 after this thread have incremented it and written it back, and then this thread over here would read the 2 and increment that to 3 and write.

that back. However, so they are copying the count field at exactly the same time up into the registers. Well, they both get the value one up there. Now what happens is both of them updates this value to two and then write it back. So as you can see, one update is now missing and there are ways to solve that in Java. I will not get too much into them here. I will mention it a little bit later, but you can use either synchronized blocks or you can use volatile variables. And both of these two key words and their functions are covered in separate videos and separate tutorials. But if you check out the description below the video, you can find links to those. Another problem that can arise is data right visibility. So for instance, let's imagine that these two threats, they actually access this object with some time in between. So first threat one copies object that count this filled up into its register up here and then it increments the value by one. So now the value is two. Now you are not guaranteed when this CPU here will write this value

back to main memory so that it is visible for the next threat. So even if the CPU is even if the threats are accessing this object sequentially so after each other not at the same time, you can risk that this update up here has not yet been written back to main memory so it is not yet visible to the other threat. This is an update visibility and you also use either volatile variables or synchronized blocks in order to counter that problem to solve that problem. So but again I will not cover synchronized and volatile in this video. Well now you know that they exist, right? And check out the description below the video for more information. Finally, I just want to talk a little bit about how the caches here work. Sometimes when a CPU wants to write the information from a register down to the RAM, it writes it through the cache here. And some CPU architectures have a cache coherence strategy implemented, which means that instead of the data here having to go into the cache and then into the main memory before it is visible to other threats to other CPUs.

this cache over here. When this threat here is requesting this object that count filled, the cashier will detect that. Oh, wait a second. This is actually available in the cache over here, so it can see the update already when it is in the cache here before it hits the main memory here. So in that way, rights can be seen earlier by other CPUs. However, remember that you do not have a guarantee of when I picked that count here will be written from the registers down to the caches, so you cannot rely on data being written here or variables being changed that they are always visible to other CPUs even if you have cache coherence strategies implemented at the hardware level. So to sum it up, in order to be sure that you avoid race conditions and that rights are always visible to other threats, then you need to use the synchronized blocks or use the volatile a key word for variables. Now let me just demonstrate quickly two situations which will show you this race condition and the visibility problem here in practice, but first let me show you a code example where the problem is

not present. Let me just remove these local variables because we don't need them anymore. Okay, so here we make to run herbals and run apples can be executed by threats. So I can also create two threats here: threat 1 and threat to. I pass one number one and runnable two to each threat, and I give the threats a name threat 102. Then we start the threats. Now the runnable that I'm passing here, what it does is it counts to 1 million. And it does so by iterating through a loop 1 million times. And for each iteration in the loop, it increments it account variable, which is a member variable as you can see up here. So it's not a local variable, it's a member variable. And then when the loop is done, it prints out what the final result of the count is. And if we go back here, and then we can see that since each thread has its own runnable, they are not actually sharing any data at all. And that means that we expect the count to be 1 million for each runnable. So we

expect two times 1 million to be printed out. And now let's run this code example here and see what happens. Look at that, we get 1 million here and 1 million here for each thread. Now let's see what happens if the two threads share the runnable. Okay, now that is how it looks here. Now we only create one runnable here. I create two threads and they get the same runnable, that means they are executing the same code within the same object. Okay, so that means that now two threads are executing this loop at the same time and at the same time, and they are incrementing this same variable because we have 1 runnable in the application running which is shared between two threads. So now if the counting was done exactly precisely synchronized, then we would expect the result to be 2 million, right? Because we have two threads which each iterate through the loop 1 million times and for each iteration in the loop increments the count variable once. However, as you will see, the end result is usually below two

million. Let's run the code here, and you can see each thread here got to like 1.3 million, 169, right. Let's try to run it again. See, now it got a different result. C32 got 109,900, 1 million and 91 thousand, and the other one got 1.9 million. And that is because of the effect that I just told you about, that the threads are reading the value of the count variable and then updating them and then writing them back. So, instead of having a precise count, they overwrite each other's accounts. They cannot see that the one is currently one thread is currently in the process of updating the value. So, that's why the count will be imprecise. If we wanted to fix that, we could do so simply by wrapping this block and this the incrementation or the count variable in a synchronized block like this. This is not a very pretty implementation. It's not very efficient either, but it shows that the problem now disappears. Now you can see threat to

doesn't get so high account, and that is okay, but the last threat to finish the loop with 1 million iterations reaches the result 2 million, and that is because now only one thread at a time can ever read, increment, and write the count variable at a time, and that means that we are now avoiding the race conditions, and we are also avoiding the right visibility problem. That's all for this video about Java threads and how they access memory, and how local variables and objects are stored inside of the Java virtual machine, and how that maps onto a modern CPU architecture. If you liked the video, hit the like button, and if you want to see more videos like this, subscribe to my channel. Remember to check out the description below the video for a link to a textual version of this tutorial, as well as links to other videos in my Java concurrency playlist.

The Java Memory Model - The Basics

The Java Memory Model - The Basics