Java memory management: detailed explanation of allocation and recycling strategies

Table 3-4 Common parameters related to garbage collection plus -XX: UseSerialGC

Conceptually, the memory allocation of objects should be allocated on the heap (in fact, it may also be dismantled into scalar type and allocated indirectly on the stack[1]). Under the classic generation design, new objects are usually allocated in the young generation. In rare cases (for example, the object size exceeds a certain threshold), they may also be allocated directly in the old generation. The rules for object allocation are not fixed. The "Java Virtual Machine Specification" does not stipulate the creation and storage details of new objects. This depends on which garbage collector the virtual machine is currently using and the memory-related functions in the virtual machine. Parameter settings.

Objects are allocated in Eden first

In most cases, objects are allocated in the new generation Eden area. When the Eden area does not have enough space for allocation, the virtual machine will initiate a Minor GC.

Large objects enter the old generation directly

Large objects refer to Java objects that require a large amount of continuous memory space. The most typical large objects are those with very long characters. String, or array with a large number of elements. The byte[] array in the examples in this section is a typical large object. Large objects are outright bad news for the memory allocation of virtual machines. The worse news than encountering a large object is encountering a group of "short-lived large objects" that "live and die". We write programs Care should be taken to avoid this.

The reason why large objects should be avoided in the Java virtual machine is that when allocating space, it can easily cause garbage collection to be triggered in advance when the memory clearly still has a lot of space, in order to obtain enough continuous space to place them properly. , and when copying objects, large objects mean high memory copy overhead. The HotSpot virtual machine provides the -XX: PretenureSizeThreshold parameter, which specifies that objects larger than the set value are directly allocated in the old generation. The purpose of this is to avoid copying back and forth between the Eden area and the two Survivor areas, resulting in a large number of memory copy operations.

-XX: The PretenureSizeThreshold parameter is only valid for the two new generation collectors, Serial and ParNew. HotSpot's other new generation collectors, such as Parallel Scavenge, do not support this parameter. If you must use this parameter for tuning, consider the collector combination of ParNew and CMS.

The virtual machine defines an object age (Age) counter for each object, which is stored in the object header. After a Minor GC, the age increases by 1 year. When its age increases to a certain degree (default is 15), it will be promoted to the old generation. The age threshold for an object to be promoted to the old generation can be set through the parameter -XX: MaxTenuringThreshold.

In order to better adapt to the memory conditions of different programs, the HotSpot virtual machine does not always require that the age of the object must reach -XX: MaxTenuringThreshold In order to be promoted to the old generation, if the sum of the sizes of all objects of the same age in the Survivor space is greater than half of the Survivor space, objects whose age is greater than or equal to this age can directly enter the old generation without waiting for the age required in -XX: MaxTenuringThreshold.

Before Minor GC occurs, the virtual machine must first check whether the maximum available continuous space in the old generation is greater than the total space of all objects in the new generation. If this If the conditions are met, then Minor GC can ensure safety this time. If it is not established, the virtual machine will first check whether the setting value of the -XX: HandlePromotionFailure parameter allows guarantee failure (Handle Promotion Failure); if it is allowed, it will continue to check whether the maximum available continuous space in the old generation is greater than the average value of objects promoted to the old generation. If the size is greater than the size, a Minor GC will be attempted, although this Minor GC is risky; if it is less than the size, or the -XX: HandlePromotionFailure setting does not allow risk, then a Full GC will be performed instead. After JDK 6 Update 24, the test results are different. The -XX: HandlePromotionFailure parameter will no longer affect the space allocation guarantee strategy of the virtual machine. Observe the source code changes in OpenJDK (see code list 3 -12), although the -XX: HandlePromotionFailure parameter is also defined in the source code, it is no longer used in the actual virtual machine. The rules after JDK 6 Update 24 become that as long as the continuous space of the old generation is greater than the total size of the new generation objects or the average size of previous promotions, Minor GC will be performed, otherwise Full GC will be performed.

The above is the detailed content of Java memory management: detailed explanation of allocation and recycling strategies. For more information, please follow other related articles on the PHP Chinese website!