This is the first day of my participation in the August More Text challenge
Java memory model
Java memory model does not know, how to internal volume old employees
- The Java memory model refers to how the Java virtual machine uses the computer’s memory.
- The Java memory model specifies how and when different threads can see other threads writing values of shared variables, and how to synchronize access to shared variables if necessary.
Internal Java memory model
- The Applicable Java memory model within the JVM allocates memory between the heap and thread stacks.
- Each thread in the Java virtual machine has its own thread stack, which changes as the thread executes code.
- The thread stack also contains all local variables for each executing method (all methods on the call stack). A thread can only access its own thread stack, and each thread also has its own version of local variables.
- All local variables of primitive types are stored entirely in the thread stack and therefore not visible to other threads. One thread can pass a copy of the original variable to another thread, but it cannot share the original local variable itself.
- The heap contains objects created by all threads.
- An object on the heap can be accessed by all threads that reference the object. When a thread can access an object, it can also access the object’s member variables. If two threads call methods on the same object at the same time, they both have access to the object’s member variables, but each thread has its own copy of local variables.
public class MyRunnable implements Runnable() { public void run() { methodOne(); } public void methodOne() { int localVariable1 = 45; MySharedObject localVariable2 = MySharedObject.sharedInstance; / /... do more with local variables. methodTwo(); } public void methodTwo() { Integer localVariable1 = new Integer(99); / /... do more with local variable. } }Copy the code
public class MySharedObject {
//static variable pointing to instance of MySharedObject
public static final MySharedObject sharedInstance =
new MySharedObject();
//member variables pointing to two objects on the heap
public Integer object2 = new Integer(22);
public Integer object4 = new Integer(44);
public long member1 = 12345;
public long member2 = 67890;
}
Copy the code
- As shown in the code above, each thread executing methodOne() creates its own copy, localVariable1 and localVariable2 in their respective threads. There is only one copy of a static variable, so localVariable2 for both threads points to the same copy of a static variable in the heap. LocalVariable1 is stored in the respective stacks.
- With methodTwo(), each thread creates an object in the heap and points to its own object.
Hardware memory architecture
- The hardware memory architecture is different from the Java internal memory architecture. The following is a simplified diagram of the hardware memory architecture
- Computers typically have multiple cpus, each with its own register, which can perform operations much faster than memory.
- Each CPU also has its own CPU cache, which is also faster for a CPU to access than main memory, but usually not as fast as registers.
- The computer also has main memory, which is accessible to all cpus and is much larger than CPU memory.
- When the CPU needs to access main memory, some of the contents of main memory will be read into the CPU cache, or even read into the CPU register. When the CPU needs to write something to main memory, it writes it first to registers, then to the cache, and finally flusher the value to main memory at the appropriate time.
- When the CPU needs to store something else in the cache, the values stored in the cache are usually flushed back to main memory. The CPU can write data to part of memory and flush parts of memory without having to read or write the full cache. Typically, updates are cached in smaller chunks of memory called “cache rows.” One or more cache lines can be read into cache storage, and one or more cache lines can be flushed back to main storage again.
Bridge between Java memory model and hardware memory model
- The Java memory model is different from the hardware memory architecture, which does not distinguish between heap and stack. Data in the heap and stack may reside in main memory, CPU caches, and CPU registers.
- When objects and variables can be stored in different areas of the hardware, you may face the following problems:
- Visibility of threads updating and writing shared variables.
- Race conditions for reading, checking, and writing shared variables.
Visibility of shared objects
- If two or more threads share an object, it is not used correctly
volatile
, updates made by one thread are not visible to other threads. - Shared objects are initially stored in main memory, and threads running on the CPU read them into the CPU’s registers and cache. An updated version of an object is not visible to other threads as long as it has not been updated and flushed back to main memory. Each thread has its own copy, in its own CPU cache.
- To solve this problem, it can be applied
volatile
The keyword. thevolatile
The keyword ensures that a given variable is read directly from main memory and always written back to main memory when updated.
Competitive conditions
- Race conditions can occur when multiple threads update the same shared object or variable.
- If thread A and thread B both read the shared variable count of 0 in main memory, both threads each perform the +1 operation. If executed sequentially, the variable increases by 2. If executed simultaneously, the final result may be just +1.
- To solve this problem, use synchronized code blocks to ensure that only one thread manipulates the variable at a time. The synchronized block also guarantees that all variables accessed within the synchronized block are read from main memory, and that when a thread exits the synchronized block, all updated variables are flushed back to main memory again, whether volatile or not.
The tail down
- How many events through the ages? Leisurely. The Yangtze River is still rolling.