Decryption of Java memory overflow persistent generation

Garbage collection is the least known part of Java programmers. They think that Java virtual machines take over garbage collection, so there's no need to worry about memory applications, allocations, and so on. However, as applications become more complex, garbage collection becomes more complex, and once garbage collection becomes more complex, the performance of the application will be greatly compromised. Therefore, Java programmers understand the mechanism of garbage collection and know how to solve the "memory overflow" problem can be of great benefit. In Java, there are two very common memory overflow issues. One is a heap memory overflow and the other is a persistent memory overflow.

Persistent Generations and class loaders

Java objects are instances of Java classes. Whenever a Java object is created, the Java Virtual machine creates an internal reference to the object and saves it in the heap. If a class is accessed for the first time, it must be loaded through a Java virtual machine. Class loading is the process of locating, finding, loading class files and parsing the class file structure. The class loader is responsible for ensuring that the correct class file is loaded. Each class file in a Java program needs to be loaded with the same type of load. The class loader is an instance of the Java.lang.ClassLoader class. So far, the ClassLoader has loaded classes in the persistent generation space.

The Java Virtual machine also creates an internal reference to the Java class that is persisted in the persistence generation. During garbage collection, Java objects and classes are treated as objects and recycled in the same way. Initially Java objects and classes are saved in the heap.

A performance optimization measure: Once the persistence generation is created, the classes is placed inside. Classes is a partial implementation of a Java virtual machine, and we should not fill the Java heap with our data structures. The persistent generation contains the following class information:

• Class method
• Class name
• Constant Pool Information
• An array of objects and types associated with the class
• Internal objects used by Java virtual machines
• Information that the compiler uses to optimize

Now that we know what the persistence generation is, let's take a look at what causes memory problems in this block.

Durable generation Space

When the Java virtual machine needs to load a new class of the definition, but there is not enough space in the persistent generation to throw the ' Java.Lang.OutOfMemoryError:PermGen space ' exception. The size that is assigned to the durable generation by default is 64MB in server mode and 32MB in client mode. There are two reasons why a persistent memory overflow problem can occur.

The first reason may be that you have an application or a server that already has a lot of classes in your persistent generation that cannot accommodate all of the classes.

-xx:maxpermsize=xxxm

If the problem is caused by a large number of classes leading to the lack of space in a persistent generation, then you can increase the size of the persistence generation by –XX:MAXPERMSIZE=XXM parameters. This will increase the amount of free space for the persistent generation to save the class. Looks like this:-xx:maxpermsize=256m

-xx:+cmsclassunloadingenabled

This parameter indicates whether the class offload function is enabled when using the CMS garbage collection mechanism. By default this is set to not enabled, so you want to enable this feature you need to explicitly set the following parameters in the Java parameters:

-xx:+cmsclassunloadingenabled

If you enable cmsclassunloadingenabled, garbage collection cleans up persistent generations and removes classes that are no longer in use. This parameter is only useful if the USECONCMARKSWEEPGC is also enabled. The parameters are as follows:

-xx:+useconcmarksweepgc

-xx:+cmspermgensweepingenabled

This parameter indicates whether the persistence generation will be cleaned up. The default is no cleanup, so we need to explicitly set this parameter to debug a persistent memory overflow problem. This parameter is removed in Java6, so you need to use-xx:+cmsclassunloadingenabled if you are using JAVA6 or later version. The parameters that resolve the persistent memory size problem will look like this:

-XX:MAXPERMSIZE=128M-XX:+USECONCMARKSWEEPGC xx:+cmsclassunloadingenabled

Memory leaks

The second reason may be a memory leak. So how does the loaded class become unused?

In Java, the class is usually permanently present. Once the class is loaded, they stay in memory, even if the application on the server is stopped. A class library that dynamically generates class like Cglib will use a lot of persistent generation space because it dynamically creates a lot of class. Frequent use of proxy classes created at run time. When a class definition can be reused for multiple instances, it is easy to create a new proxy class.

Sping and hibernate often represent certain classes. The class of these proxies is loaded by the ClassLoader. The resulting class definition, if not recycled all the time, will cause the persistent generation space to be full soon.

You need to determine if a memory leak is causing the persistent generation of space problems while addressing it. Increasing the size of the persistent generation space will not be useful, it will only delay its occurrence, as it will still be filled at some point in time.

If you are experiencing a memory leak with Tomcat, the latest version of Tomcat has the ability to handle some memory leaks. For details, please see:

• Http://wiki.apache.org/tomcat/MemoryLeakProtection

Summarize

Once you have a persistent content overflow problem, you need to find out whether the problem is caused by loading a large number of class files or a memory leak. If it is because the number of classes is too large, you can increase the amount of space allocated for the long term to solve this problem. If it is a memory leak, you need to cause the memory leak to be the source and locate it. Some frameworks like cglib,spring,hibernate create a large number of dynamic classes, so it is best to allocate a bit more persistent generation space for applications that use these frameworks.

Original link: http://www.javacodegeeks.com/2013/12/decoding-java-lang-outofmemoryerror-permgen-space.html

Decryption of Java memory overflow persistent generation