Java memory and GC

Java memory area and memory overflow

Memory allocation diagram in Java virtual machine:

The characteristics of each area are summarized in the following table:

Additional explanation:

In multi-threading situations, there may be multiple When threads allocate memory on the heap, memory allocation synchronization problems may occur. There are two solutions. One is to synchronize memory allocation actions; the other is to use TLAB, which means to pre-allocate a small amount of memory for each thread in the Java heap. Block thread-private local thread allocation buffer. In this way, when a thread needs to allocate memory, it will do so on its own TLAB, thus avoiding the overhead of synchronization. However, synchronization is still required when TLAB is fully allocated and reallocated;

To determine whether a class is a useless class, the conditions for "can" be recycled are: 1. All instances of the class have been recycled; 2. Load the ClassLoader of the class Has been recycled; 3 The java.lang.Class object of this class is not referenced anywhere. Note that it is only possible, not to be recycled.

Memory allocation method: The method used by the virtual machine is determined by whether the memory is regular, and whether the memory is regular is determined by the recycling algorithm.

Pointer collision: Assume that all allocated memory is placed on one side, and the free memory is placed on the other side. A pointer is used as the dividing point between the two. When memory needs to be allocated, you only need to move the pointer, so The method is called pointer collision. This method is used by Serial, ParNew and other compact recyclers

Free list: The allocated memory and free memory in the virtual machine are not regular and are intertwined with each other, so it is necessary to maintain a list to represent which Memory is available, and when you need to allocate memory, you need to query the list to find the available size of memory. This approach is called a free list. This method is used by CMS and other recyclers based on the Mark-Sweep algorithm. The memory layout of the object in the HotSpot virtual machine is as shown in the following table:

In the Java specification, only one reference type is specified. A reference to an object, but does not specify how to access the referenced data. Therefore, there are different access methods for different virtual machines. There are two main ways:

Use handles: Set aside an area in the Java heap as a handle pool to store handles. A handle includes a pointer to the object instance data and the object data type. The pointer, the address of the object's handle is stored in the reference. Reference indirectly accesses an object through a handle. The advantage is: when the object moves, you only need to change the pointer in the rectangle, and the corresponding reference does not need to be changed;

Direct access: The reference stores the object address, and the data can be directly accessed through the reference. The data objects in Java pairs contain pointers to the object's data type, such as the type pointers mentioned above. The advantage of this method is that the access speed is fast, and it saves the overhead of pointer positioning compared to the method of using handles. HotSpotVM uses this method.

The illustrations of the two usage methods are as follows: Image source http://www.th7.cn/Program/java/201604/846729.shtml

Garbage collection algorithm

To determine whether an object is dead, There are two algorithms that can no longer be used:

Reference counting algorithm: For an object, when the number of times it is referenced increases by one, the count increases by 1, and when the reference becomes invalid, it decreases by 1. When the count is 0, The object is considered dead. This algorithm is characterized by high efficiency, but it is difficult to solve the problem of mutual references between objects. This algorithm is used by MS COM technology and Python, etc.

Reachability analysis algorithm: The core of this algorithm is to start from GC Roots and detect all objects referenced. If there is no reference chain between an object and GC Roots, the object is considered dead. Java, C#, etc. are used to use this algorithm.

Objects that can be used as GC Roots include:

Objects referenced in the virtual machine stack (local variable table in the stack frame)

Objects referenced by class static properties in the method area

Objects referenced by constants in the method area

The object referenced in the Native method

has four reference strengths in Java:

Strong reference: Strong reference will never be recycled by the garbage collector

Soft reference: The system provides the SoftReference class to represent it, indicating that it is still available but not necessary Object. The timing of recycling is to recycle such references if the memory is not enough after the reference object is recycled. If it is not enough, OOM

Weak reference: Represented by the WeakReference class, this type of reference can only survive until the next garbage collection. When the garbage collector works, objects associated with only weak references will be recycled regardless of whether the current memory is sufficient. That is, as long as GC occurs, weak references must be recycled. The difference from the reference chain that no longer reaches GC Roots is that these objects can still be accessed through weak references, but objects without reference chains can never be accessed again.

Virtual reference: implemented through PhantomReference, which has no impact on the survival time of the object. The significance of its existence is to receive a system notification when the object referenced by the virtual reference is recycled.

The GC workflow of the system is shown in the figure below. In general, an object that is recycled may go through the marking process twice, and may save itself in the finalize method to avoid being recycled.

Several typical garbage collection algorithms:

Specific implementation details of the garbage collection algorithm in HotSpot VM: For accurate results, the GC needs to freeze all threads when scanning. The current mainstream Java virtualization adopts accurate GC, that is, the system knows what data type the data in each memory location is. Taking HotSpot as an example, it uses a data structure called OopMap to implement such mapping records. . With such information, the virtual machine directly knows where the object references are stored, thus avoiding the need to check the memory one by one and speeding up the GC scan. Each instruction of the program may lead to changes in reference relationships or memory data, which will lead to changes in OopMap. In this case, if a corresponding OopMap data is generated for each instruction, it will take up quite a lot of space, so a safety point is proposed. The concept (SafePoint) is that GC scan is only performed when each thread runs to the safe point corresponding to the thread, so only the OopMap can be generated for the instructions at the safe point, thus reducing the number of OopMap. The selection of safe points should take into account the comprehensive impact of GC frequency and system performance. Generally, points that "have the characteristics of allowing the program to run for a long time" such as method calls, loop jumps, and exception jumps are selected. In order to allow the threads to run to a safe point and stop for GC scanning, there are two methods: preemptive interruption and proactive interruption. There is another problem here. If it encounters a thread that is in Sleep state, for example, it will not move. If it happens not to be sleeping at a safe point, it means that it will never go to the safe point, so The concept of SafeRegion was also proposed. That is, the points in this area are safe points. After the thread enters the safe point, it will mark that it has entered the safe area, and it must wait until the GC is completed before leaving the safe area.

Various garbage collectors:

Several of the most common memory allocation rules:

Objects are allocated first in the Eden area: When the Eden area has insufficient memory, the system will initiate a faster Minor GC

Large objects enter the old generation area directly: For large objects such as long arrays and strings, allocate them directly to the old generation area. Therefore, large objects with short life cycles are likely to cause GC and should be avoided as much as possible.

Objects that survive for a long time will enter the old generation: If an object survives multiple Minor GCs in the Survivor area, 15 times by default, it will be moved to the old generation.

Dynamic object age determination: This article is combined with the previous one. If the sum of the sizes of all objects of the same age in the Survivor exceeds half of the Survivor, then the objects whose age is greater than or equal to this age will be moved to the old generation area without waiting 15 times.

Space allocation guarantee: copy collection algorithm for the new generation. If the parameters are allowed, after executing Minor GC, if all surviving objects cannot be placed in the Survivor, then many objects will be placed directly into the old generation area. If there is not enough space in the old generation, a Full GC will occur to obtain more space