Java Memory Model Analysis 2

Variables in the other's working memory cannot be accessed directly between different threads, and the transfer of variable values between threads needs to be done in main memory, with threads, main memory, and working memory interacting as shown, and very similar.

The main memory, the working memory, and the Java heap, stack, and method area of the Java memory area are not the same level of memory partitioning.!!!

The main memory, the working memory, and the Java heap, stack, and method area of the Java memory area are not the same level of memory partitioning.!!!

3.2 Inter-memory interoperability

The Java memory model defines the following eight actions for the specific interaction protocol between main memory and working memory, that is, how a variable is copied from main memory to working memory, how to synchronize from working memory to main memory.

• Lock: A variable that acts on the main memory and identifies a variable as a thread-exclusive state.

• An excellent Java programmer must understand the Java memory model, how GC works, and how to optimize GC performance, limited interaction with GC, some applications have high performance requirements, such as embedded systems, real-time systems, etc., only to comprehensively improve the management efficiency of memory To improve the performance of the entire application.

  This article discusses the JVM memory model, the GC's working principle, and several key issues in GC to improve the performance of Java programs from a GC perspective.

One, Java memory model

Officially, the Java virtual machine has a heap, the heap is the runtime data region, and all the class instances and arrays of memory are allocated from here.

The JVM primarily manages two types of memory: heap and non-heap, heap memory, which is created when a Java virtual machine is started, and non-heap memory (Non-heap memories) is memory outside the JVM heap.

In short, a heap is a Java code-readable memory that is left to the developer, and not a heap that is left to itself by the JVM, containing the required memory for the method area, internal processing of the JVM, or optimization (such as Jitcompiler,just-in-time Compiler, the immediately compiled code cache), Code for each class structure, such as running a constant pool, fields, and method data, and methods and construction methods.

When the JVM starts, it retains a fixed amount of memory to the heap memory, which is not necessarily used by the JVM, but it can be determined that this portion of the reserved memory is not used by other processes, which is -Xmx 参数指定。 allocated to the JVM when the JVM is started in the other part, As the initial heap memory usage of the JVM, this portion of memory is specified by the-XMS parameter.

When the default free heap memory is less than 40%, the JVM increases the heap until the maximum limit of-xmx, which can be specified by-xx:minheapfreeratio.

When the default free heap memory is greater than 70%, the JVM reduces the heap until the minimum limit of-XMS, which can be specified by-xx:maxheapfreeratio.

The JVM memory request process is as follows:

1. The JVM tries to initialize a chunk of memory in Eden for the relevant Java object
2. When the Eden space is sufficient, the memory request ends;
3. The JVM tries to free all inactive objects in Eden (this is a 1 or more advanced garbage collection), and if Eden space is still insufficient to fit into the new object after release, attempt to put some of the active objects in Eden into the survivor area
4. The survivor area is used as an intermediate swap area for Eden and old, and when the old area is sufficiently large, the objects in the survivor area are moved to the old area, otherwise they will remain in the survivor area.
5. When there is not enough space in the old area, the JVM performs a full garbage collection in the old area (level 0)
6. After a complete garbage collection, "Out of memory" error occurs if the survivor and old areas still cannot hold portions of objects copied from Eden, causing the JVM to be unable to create an area for the new object in the Eden area

Java is developed by C + +, it rejects some of C + + cumbersome error-prone things, introduced the concept of counter, one of which is this GC mechanism (C # borrowed from Java)

The Java language does not provide a display action method that frees allocated memory. Therefore, Java's memory management is actually the management of objects, including the allocation and release of objects.

For programmers, the allocation object uses the new keyword; When you dispose of an object, you assign null to all references to the object, so that the program cannot access the object again, and we call the object "unreachable." The GC will be responsible for reclaiming the memory space of all "unreachable" objects.

For GC, when a programmer creates an object, the GC starts to monitor the object's address, size, and usage. Typically, a GC uses a graph to record and manage all objects in the heap. In this way, you determine which objects are "accessible" and which are "unreachable". When the GC determines that some objects are unreachable, it is the GC's responsibility to reclaim those memory spaces. However, in order to ensure that the GC can be implemented on different platforms, the Java specification does not strictly govern many of the GC's behavior. For example, there are no clear rules as to what type of recovery algorithm to use, when to recycle, and so on. Therefore, different JVM implementations often have different implementation algorithms. This also brings a lot of uncertainty to the development of Java programmers. This paper studies several issues related to GC work and tries to reduce the negative impact of this uncertainty on Java programs.

In order to ensure that the GC can be implemented on different platforms, the Java specification does not strictly govern many of the GC's behavior. For example, there are no clear rules as to what type of recovery algorithm to use, when to recycle, and so on. Therefore, different JVM implementations often have different implementation algorithms. This also brings a lot of uncertainty to the development of Java programmers.

In order to ensure that the GC can be implemented on different platforms, the Java specification does not strictly govern many of the GC's behavior. For example, there are no clear rules as to what type of recovery algorithm to use, when to recycle, and so on. Therefore, different JVM implementations often have different implementation algorithms. This also brings a lot of uncertainty to the development of Java programmers.

In order to ensure that the GC can be implemented on different platforms, the Java specification does not strictly govern many of the GC's behavior. For example, there are no clear rules as to what type of recovery algorithm to use, when to recycle, and so on. Therefore, different JVM implementations often have different implementation algorithms. This also brings a lot of uncertainty to the development of Java programmers.

Java Memory Model Analysis 2