Goodbye to Java 8’s new features, permgen_ Power node Java college sorting

Many developers have seen the problem of "Java. Lang. outofmemoryerror: permgen space" in their systems. This is often caused by memory leaks related to class loaders and the creation of new class loaders, usually during code hot deployment. Compared with the formal product, this problem occurs more frequently on the development machine. The most common "problem" in the product is that the default value is too low. A common workaround is to set it to 256MB or higher.

A brief introduction to permgen space

The full name of permgen space is permanent generation space, which refers to the permanent storage area of memory. Tell me why memory benefits: this part is used to store the information of class and meta. When class is loaded, it is placed in the permgen space area, which is different from the heap area where instances are stored. Therefore, if your app will load many classes, Permgen space errors are likely to occur. This error is common when the web server pre compiles JSPS.

There are many kinds of JVMs, such as Oracle sun hotspot, Oracle JRockit, IBM J9, Taobao JVM, etc. of course, the Wulin alliance leader is hotspot, which is indisputable. It should be noted that permgen space is Oracle sun hotspot, and JRockit and J9 do not have this area.

Metaspace is the birth of a new memory space

Jdk8 hotspot JVM will remove the persistent area and use local memory to store class metadata information, which is called Metaspace. This is very similar to Oracle JRockit and IBM JVM's, as shown in the following figure

This means that there will be no more Java Lang. outofmemoryerror: the permgen problem no longer requires you to tune and monitor the use of memory space... But please wait, it's too early to say so. By default, these changes are transparent. Our next presentation will let you know that you still need to pay attention to the memory occupation of class metadata. Keep in mind that this new feature does not magically eliminate memory leaks caused by classes and class loaders.

Metaspace in java8 is summarized as follows:

State of permgen space

This part of memory space will be completely removed.

JVM parameters: permsize and maxpermsize are ignored and warned if they are set when enabled.

Metaspace memory allocation model

Most of the class metadata is allocated in local memory.

The "klasses" used to describe class metadata has been removed.

Metaspace capacity

By default, class metadata is limited only by the available local memory (the capacity depends on the available virtual memory size of a 32-bit or 64 bit operating system).

The new parameter (maxmetaspacesize) is used to limit the size of local memory allocated to class metadata. If this parameter is not specified, the Metaspace will be dynamically adjusted as needed at run time.

Metaspace garbage collection

Garbage collection for dead classes and class loaders will be performed when the metadata usage reaches the set value of the "maxmetaspacesize" parameter.

Timely monitoring and adjusting the meta space is necessary to reduce the garbage collection frequency and delay. Continuous meta space garbage collection indicates that there may be memory leaks caused by classes and class loaders or improper size settings.

Impact of Java heap memory

Some miscellaneous data has been moved to Java heap space. After upgrading to jdk8, you will find that the Java heap space has increased.

Metaspace monitoring

The usage of meta space can be viewed from hotspot1 8 in the detailed GC log output.

Jstat and jvisualvm have been updated when testing with the B75 version, but you can still see the emergence of the old permgen space.

It has been fully explained in theory. Let's observe the new memory space through the "leak" program

Permgen vs. Metaspace runtime comparison

To better understand the runtime behavior of Metaspace memory space,

The following scenarios will be tested:

1. Use jdk1 7 run the Java program, monitor and exhaust the default 85MB of permgen memory space.

2. Use jdk1 8 run the Java program to monitor the dynamic growth of the memory space of the new Metaspace and the garbage collection process.

3. Use jdk1 8 run a java program to simulate running out of 128MB Metaspace memory space set by the "maxmetaspace size" parameter.

Firstly, a code simulating permgen oom is established

The above is a simple classA. Compile it into class bytecode and put it under D: / classes. Use urlclassloader to load this type in the test code and compile it into class

The virtual machine parameters are set as follows: - verbose - verbose: GC

The - verbose parameter is set to get information about type loading and unloading

Set - verbose: GC to get information about garbage collection

JDK 1.7 @ 64 bit C permgen depletion test

Java1. The default permgen space of 7 is 85 MB (or can be specified through - XX: maxpermsize = xxxm)

As can be seen from the screenshot of the jvisualvm above, when more than 60000 classes are loaded, permgen is exhausted. We can also observe the depletion process through the program and GC output.

Program output (extracted part)

JDK 1.8 @64-bit C Metaspace dynamic resizing test

Java's Metaspace space: unrestricted (default)

As can be seen from the screenshot above, the JVM Metaspace has been dynamically expanded, and the use of local memory has increased from 20MB to 646mb, so as to meet the growing memory occupation demand of class data in the program. We can also observe the JVM's garbage collection event -- an attempt to destroy a dead class or classloader object. However, due to the leakage of our program, the JVM has no choice but to dynamically expand the Metaspace memory space. The program loads more than 100000 classes without oom events.

JDK 1.8 @64-bit C Metaspace restricted test

Metaspace space of Java: 128MB (- XX: maxmetaspace size = 128M)

As can be seen from the screenshot of the jvisualvm above: when more than 20000 classes are loaded, the Metaspace is exhausted; And jdk1 7 runtime is very similar. We can also observe the depletion process through the program and GC output. Another interesting phenomenon is that the reserved native memory footprint is twice the set maximum size. This may indicate that if possible, the meta space capacity size policy can be fine tuned to avoid the waste of local memory.

You can see the following exception from the output of the Java program.

When maxmetaspacesize is set, the memory of the space will still be exhausted, resulting in a "java.lang.outofmemoryerror: metadata space" error. Because the leak of class loader still exists, and usually Java does not want to consume native memory indefinitely, it seems reasonable to set a limit similar to maxpermsize.

summary

1. Before, the JVM will eat up that space whether it is needed or not... If it is set too small, the JVM will die; If it is set too large, this memory will be wasted by the JVM. Theoretically, you can completely ignore this now, because the JVM will automatically adjust to "appropriate size" at runtime;

2. Improve the performance of full GC. During full GC, there is no need to scan between metadata and metadata pointers. Don't underestimate these nanoseconds;

3. The hidden danger is that if the program has memory leakage, like oomtest, constantly expanding the space of Metaspace will lead to insufficient memory of the machine, so it is still necessary to debug and monitor.