Shulou(Shulou.com)05/31 Report--

In this article, the editor introduces in detail "what is the strategy of Java memory allocation and recycling". The content is detailed, the steps are clear, and the details are handled properly. I hope that this article "what is the strategy of Java memory allocation and recycling" can help you solve your doubts.

Table 3-4 commonly used parameters related to garbage collection plus-XX: + UseSerialGC

The memory allocation of objects should, conceptually, be allocated on the heap (in fact, it is also possible to be split into scalar types after instant compilation and indirectly allocated on the stack [1]). Under the design of classical generation, new objects are usually distributed in the new generation, and in a few cases (for example, the object size exceeds a certain threshold), it may also be allocated directly in the old age. The rules for object allocation are not fixed, and the Java virtual machine specification does not specify the details of the creation and storage of new objects, depending on what kind of garbage collector the virtual machine is currently using and the setting of memory-related parameters in the virtual machine.

Objects are assigned first in Eden

In most cases, objects are allocated in the Cenozoic Eden zone. When there is not enough space in the Eden zone to allocate, the virtual machine will initiate a Minor GC.

The big object went straight into the old age.

Large objects are Java objects that require a lot of contiguous memory space. The most typical large objects are long strings or arrays with a large number of elements. The byte [] array in the example in this section is a typical large object. Large objects are out-and-out bad news for the memory allocation of virtual machines, and the worse news than meeting a large object is that we encounter a group of "short-lived big objects" that are "dying", which we should avoid when writing programs.

The reason for avoiding large objects in the Java virtual machine is that when allocating space, it is easy to trigger garbage collection in advance when there is still a lot of memory to obtain enough contiguous space to place them.

When making objects, large objects mean high memory replication overhead. The HotSpot virtual machine provides the-XX:PretenureSizeThreshold parameter, which specifies that objects larger than this setting are allocated directly in the old age. The purpose of this is to avoid copying back and forth between the Eden area and the two Survivor zones, resulting in a large number of memory replication operations.

The-XX:PretenureSizeThreshold parameter is only valid for Serial and ParNew Cenozoic collectors. Other Cenozoic collectors of HotSpot, 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.

Long-term surviving objects will enter the old age.

The virtual machine defines an object age (Age) counter for each object, which is stored in the object header. Each time the Minor GC is passed, the age increases by 1 year, when its age increases to a certain range.

Degrees (default is 15), will be promoted to the old age. The age threshold for the promotion of an object can be set by parameter-XX:MaxTenuringThreshold.

Dynamic object age determination

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 promote the old age. If the total size of all objects of the same age in the Survivor space is more than half of the Survivor space, the objects whose age is greater than or equal to that age can directly enter the old age without waiting for the age required in-XX:MaxTenuringThreshold.

Space allocation guarantee

Before the occurrence of Minor GC, the virtual machine must first check whether the maximum contiguous space available in the old era is larger than the total space of all objects in the new generation. If this condition is true, this time Minor GC can ensure that it is secure. If not, the virtual machine will first check whether the setting of the-XX:HandlePromotionFailure parameter allows guarantee failure (HandlePromotionFailure); if so, it will continue to check whether the maximum available contiguous space in the old age is larger than the average size of the object promoted to the old age, and if so, it will try to conduct a Minor GC, although this Minor GC is risky. If it is less than, or the-XX:HandlePromotionFailure setting does not allow risk, then do a Full GC instead.

After JDK 6 Update 24, the test results are different. The-XX:HandlePromotionFailure parameter no longer affects the space allocation guarantee policy of the virtual machine. Observe the changes in the source code in OpenJDK (see listing 3-12). Although the-XX:HandlePromotionFailure parameter is also defined in the source code, it will no longer be used in the actual virtual machine. The rule after JDK 6 Update 24 is that as long as the continuous space of the old age is larger than the total size of the new generation or the average size of previous promotions, Minor GC will be carried out, otherwise Full GC will be carried out.

After reading this, the article "what is the strategy of Java memory allocation and recycling" has been introduced. If you want to master the knowledge of this article, you still need to practice and use it to understand it. If you want to know more about related articles, welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.