Java memory and GC, Java memory GC

Java memory and GC, Java memory GC

Chapter 2 Summary

Java memory overflow

Memory Distribution chart in Java Virtual Machine:

The features of each region are summarized as follows:

Note:

• In the case of multiple threads, multiple threads may allocate memory on the heap. There may be a synchronization problem with memory allocation. There are two solutions, one being synchronous memory allocation; the other is to use TLAB, that is, in the Java heap, allocate a buffer for a local thread that is private to a small thread in advance for each thread. In this way, the thread needs to allocate memory on its own TLAB to avoid synchronization overhead. However, synchronization is still required when TLAB is fully allocated and re-allocated;
• To determine whether a class is useless, the condition that "yes" can be recycled is: 1. All instances of this class have been recycled; 2. ClassLoader of this class has been recycled; 3. lang. the Class object is not referenced anywhere. Note: Only yes, rather than being recycled.

Memory Allocation Method: The method used by the VM is determined by whether the memory is regular, and whether the memory is regular is determined by the recycle algorithm.

Objects in the HotSpot Virtual MachineMemory LayoutSee the following table:

In the Java specification, the reference type only specifies a reference pointing to an object, but does not specify how to access the referenced data. Therefore, different virtual machines have differentAccess MethodThere are two main methods:

Illustration of the two ways of use, such as: Picture source http://www.th7.cn/Program/java/201604/846729.shtml

 

Garbage collection Algorithm

There are two algorithms that determine whether an object is dead and cannot be used again:

Can be usedGC Roots objectInclude:

• Objects referenced in the Virtual Machine stack (the local variable table in the stack frame)
• Objects referenced by class static attributes in the Method Area
• Objects referenced by constants in the method Area
• Objects referenced in the Native Method

In JavaFour types of reference strength:

• Strong reference: strong reference will never be recycled by the Garbage Collector
• Soft reference: The system provides the SoftReference class to indicate that there are still but not required objects. The recovery time is to recycle such references if the memory is not enough after the referenced object is recycled. If not, OOM
• Weak references: The WeakReference class indicates that such references can only survive until the next garbage collection. When the garbage collector is working, only objects associated with weak references will be reclaimed regardless of whether the current memory is sufficient. That is, as long as GC occurs, weak references must be recycled. The difference between it and the reference chain that has no GC Roots is that it can still access these objects through weak references, but objects without the reference chain will never be accessed again.
• Virtual Reference: It is implemented through PhantomReference, which has no impact on the object's survival time. Its significance is that it can receive a system notification when the object being referenced by Virtual Reference is recycled.

System GC WorkflowAs shown in, in general, an object may be recycled twice, and may save itself in the finalize method to avoid being recycled.

Several TypicalGarbage collection Algorithm:

 

Detailed Implementation of the garbage collection algorithm in the HotSpot VM: to ensure accurate results, GC needs to freeze all threads during scanning. Currently, the mainstream Java virtual machine uses accurate GC, that is, the system knows the Data Type of each memory location. For example, HotSpot usesOopMapTo achieve such a ing record. With this information, the virtual machine will directly know where the object references are stored, so as to avoid checking the memory one by one and speed up GC scanning. Every instruction of the program may lead to changes in the reference relationship or memory data, which will lead to changes in OopMap. In this case, if a corresponding OopMap data is generated for each instruction, it takes a considerable amount of space.Security PointConcept (SafePoint), that is, GC scanning is performed only when each thread is running to the corresponding security point of the thread. Therefore, you only need to generate an OopMap for the command on the security point, this reduces the number of OopMap instances. The selection of security points should take into account the comprehensive impact of GC frequency and system performance. Generally, we should select "features that make programs run for a long time", such as method call, loop jump, and exception jump. To stop threads from running to a security point for GC scanning, there are two methods: preemptive interruption and proactive interruption. There is another problem here. If a thread, for example, is in Sleep state, it will not move around. If it happens not to be Sleep at a security point, this means that it will never come to the security point, so I proposedSecurity Zone(SafeRegion. That is, all points in this region are security points. After the thread enters the security point, it will mark itself as entering the security area, and it will leave the security zone only after GC is executed.

 

VariousGarbage Collector:

 

Several of the most commonMemory Allocation Rules:

• Objects are preferentially allocated in the Eden area: When the memory in the Eden area is insufficient, the system will initiate a fast Minor GC
• Large objects directly enter the old age: for large objects such as long arrays and strings, they are directly allocated to the old age. Therefore, for a large object with a short life cycle, GC is very likely to occur and should be avoided as much as possible.
• Objects that survive for a long time will enter the old age: if a Minor GC still exists after multiple times in the same vor region, 15 times by default, the objects will be moved to the old age region.
• Dynamic Object age determination: This is a combination of the previous one. If the size of all objects of the same age in a pair vor exceeds half of that of the pair vor, objects older than or equal to this age will be moved into the old age zone, and do not have to wait until 15 times
• Space allocation guarantee: A New Generation replication collection algorithm. If the parameter permits, after Minor GC is executed, if the surviving objects cannot all be placed in the same vor, many objects will be directly placed in the old age zone. If there is not enough space in the old age, Full GC will occur to get more space.