The memory model
Methods area
The method area is a memory area shared by threads, also known as non-heap. It is used to store data, such as class information, constants, static variables, and code compiled by the real-time compiler, that has been loaded by the VIRTUAL machine. According to the Java VIRTUAL Machine specification, when the method area cannot meet the memory allocation requirements, OutOfMemoryError is thrown. It is worth noting that there is an area in the methods area called the Runtime Constant Pool, which is used to store the various literals and symbolic references generated by the compiler that will be stored in the Runtime Constant Pool after the class is loaded for later use.
The heap
The Java heap is also belongs to the thread Shared memory region, it created in the virtual machine startup, is managed by a Java virtual machine piece in memory of the largest, is mainly used for storing an object instance, almost all object instances are allocated memory here, pay attention to the Java heap garbage collector management is the main area, so a lot of times is also called the GC heap, OutOfMemoryError is thrown if there is no memory in the heap to complete the instance allocation and the heap can no longer be extended.
The virtual machine stack
An area of data that is private to the thread, created at the same time as the thread, totals with respect to the thread, and represents the memory model of the execution of Java methods. Each method execution creates a stack frame to store the method’s variator, operand stack, dynamically linked method, return value, return address, and so on. Each method from the end of the call is a frame in and out of the virtual machine stack process.
Local method stack
The local method stack belongs to the private data area of the thread, which is mainly related to the Native methods used by the VIRTUAL machine. In general, we do not need to care about this area
Program counter
A data area that is private to a thread and is a small memory space that represents the bytecode signal indicator that is being executed by the current thread. When the bytecode interpreter works, it selects the next bytecode instruction to be executed by changing the value of this counter. Branch, loop, jump, exception handling, thread recovery and other basic functions need to be completed by this counter.
JMM
The Java Memory Model, or JMM, is an abstract concept that doesn’t really exist. It describes a set of rules or specifications that define how variables in a program (including instance fields, static fields, and the elements that make up array objects) can be accessed.
The Java memory model specifies that all variables are stored in main memory;
The entity of JVM scheduling is threads, and the JVM creates private memory space (working memory) for each thread;
Thread operations should be in their own private memory space (working memory), can not operate on variables in the shared main memory, working memory stores the copy of variables in the main memory; Copy variables from main memory to its own working memory space, and then operate on variables, and write variables back to main memory; (key)
JMM revolves around atomicity, order, and visibility.
Main memory
The main store is Java instance objects, including member variables and local variables, as well as shared class information, constants, static variables. Since it is a shared data area, multiple threads accessing the same variable may find thread-safety issues.
The working memory
The main store is all local variables of the current method (working memory stores copies of variables in main memory). Each thread can only access to their working memory, the threads of the local variable is not visible to other threads, even two threads execute the same code, they will be in their respective working memory to create belong to the local variables of the current thread, of course, also including the bytecode line number indicator, the related information of Native method; Note that since the data in the working memory is the private data of each thread, threads cannot access the working memory with each other. Therefore, data stored in the working memory is not thread-safe. Since different threads cannot access each other’s working memory at the same time, communication between threads (passing values) must be done through main memory.
Data types stored in main memory versus working memory
According to the virtual machine specification, for member methods in an instance object:
1. A local variable is the basic data types (Boolean, byte, short, char, int, long, float, double), will be directly stored in working memory (JVM frame stack). Local variables are reference types, and references to variables are stored in working memory (the frame stack of the JVM stack), while object instances are stored in main memory (the heap).
2. Whether a member variable is a primitive data type or wrapper type (Integer, Double, etc.) or a reference type, variable references and instances are stored in main memory (heap area);
Global variables (static modified variables, also called class variables) are stored in main memory (method area).
For the above mentioned the data stored in the working memory is divided into basic types and reference types, this is my doubt, some people say that all of them are reference types, he made a hypothesis, if the variables in the main memory is very big, so if it is a copy of the value, may cause the thread safety problem? So he thinks it’s all quotes. For this question, welcome to leave a message to discuss.
The actual location of memory
From the Java memory model, the hardware memory architecture, and the implementation of Java multithreading, we should have realized that the execution of multithreading eventually maps to the hardware processor for execution. Only for hardware memory registers, the concept of cache memory, primary memory, not the working memory (thread the private data area) and main memory (heap memory), that means the division of the memory of the Java memory model for hardware memory and does not have any effect, because the JMM is an abstract concept, is a set of rules that does not actually exist, Whether working memory data or data from main memory, for computer hardware will be stored in the computer main memory, of course, may also be stored in the CPU caches or register, so in general, the Java memory model and the computer hardware memory architecture is an overlapping relations, is an abstract concept division and cross of the real physical hardware.
The memory model differs from the JMM
The PARTITIONING of JMM and Java memory regions is a different conceptual level. More properly, THE JMM describes a set of rules, while the latter is the actual partitioning.
The only similarity between the JMM and Java memory regions is that there are shared data regions and private data regions. In the JMM, main memory belongs to the shared data area, which to some extent should include the heap and method area; Working memory (thread-private data area), to some extent, should include program counters, virtual machine stacks, and local method stacks.
In some places, we might see main memory described as heap memory and working memory as thread stack, but they all mean the same thing
Reference:
- JAVA thread safety memory model