Understanding of Java's PermGen concept, and how to deal with related problems

PermGen space is the full name of Permanent Generation space, refers to the memory of the permanent storage area Outofmemoryerror:permgen space from the surface is the memory benefits, The solution must also be to increase memory. Tell me why memory Benefits: This section is used to store class and meta information, and class is placed in the PermGen space area when it is loaded, unlike the heap area where instance is stored, GC (garbage Collection) PermGen space will not be cleaned during the main program's run time, so if your app will load many classes, you will likely have permgen space errors. This error is common when the Web server pre-compile the JSP. If you have a large number of third-party jars under your web app that are larger than the JVM's default size (4M), this error message will be generated.

Workaround: Manually set the MaxPermSize size
Correction Method:-xms256m-xmx256m-xx:maxnewsize=256m-xx:maxpermsize=256m

Modify Tomcat_home/bin/catalina.sh
Java_opts= "-server-xx:permsize=64m-xx:maxpermsize=128m
Recommendation: Move the same third-party jar files to the Tomcat/shared/lib directory, which can reduce the memory consumption of the jar document.

The Sun documentation explains this:

Java.lang.OutOfMemoryError:PermGen Space

The detail message PermGen space indicates that the permanent generation are full. The permanent generation is the area of the heap where class and method objects are stored. If an application loads a very large number of classes and then the size of the permanent generation might need to be increas Ed using the-xx:maxpermsize option.

Interned java.lang.String objects is also stored in the permanent generation. The Java.lang.String class maintains a pool of strings. When the Intern method was invoked, the method checks the pool to see if a equal string is already in the pool. If there is and then the Intern method returns it; Otherwise it adds the string to the pool. In more precise terms, the Java.lang.String.intern method was used to obtain the canonical representation of the String; The result is a reference to the same class instance that would being returned if that string appeared as a literal. If an application interns a huge number of strings, the permanent generation might need to being increased from its default s Etting.

When this kind of error occurs, the text String.intern or Classloader.defineclass might appear near the top of the stack T Race is printed.

The Jmap-permgen command prints statistics for the objects of the permanent generation, including information about Inter Nalized String instances. See 2.6.4 Getting information on the Permanent Generation.

Here are some of the problems someone is having:

SUN Jdk+tomcat 5.5.20 Run the service when encountered problems, the server will hang after a few days, and reported java.lang.OutOfMemoryError:PermGen space anomalies.

It is found that many people attribute the problem to: Spring,hibernate,tomcat because they dynamically produce classes that cause the permanent heap overflow in the JVM. Then there are a few opinions about how to upgrade the Tomcat version to the newest or even simply without Tomcat. There are also doubts about the spring issue, which is hotly debated on the Spring Forum, as spring uses cblib in AOP to generate many classes dynamically.

But the question is why the same problem arises from the open source of these trump cards, is it a more basic reason? Tomcat answered this very vaguely in q&a. (Why does the memory usage increase when I redeploy a Web application? Because the Classloader (and the Class objects it loaded) cannot be recycled. They is stored in the permanent heap generation by the JVM, and if you redepoy a new class loader is created, which LOA DS Another copy of all these classes. This can cause oufofmemoryerrors eventually. ）

Then someone checked the more basic JVM and found the key to the problem. It turns out that the Sun's JVM has divided the memory into different areas, one of which is the permanent area used to store very many classes and class descriptions. Sun was designed to think the area was fixed when the JVM started, but he didn't expect it to be used so extensively. And this area has a special garbage recovery mechanism, now the problem is that the dynamic loading class to this area, the GC has no way to recycle!

The most radical solution to this bug is not to use Sun's JDK, but instead switch to Bea's jrokit.

A outofmemoryerror error occurred while redeploy in Tomcat.

There are several possible reasons for this:

1, Proxool is used because the Proxool contains an older version of Cglib.
2, log4j, better not, just use common-logging.
3, the old version of Cglib, quickly update to the latest version.
4, update to the latest hibernate3.2
5, here the Tomcat environment, for example, other Web servers such as Jboss,weblogic and so on is the same reason.

Second, Java.lang.OutOfMemoryError:Java heap space
Heap Size Setting
The JVM heap setting is the set of memory space that the JVM can provision during the run of the Java program. The JVM automatically sets the value of the heap size when it is started.
Its initial space (that is,-XMS) is 1/64 of the physical memory, and the maximum space (-XMX) is 1/4 of the physical memory. You can use options such as the-XMN-XMS-XMX provided by the JVM to
To set. The size of Heap size is the sum of young Generation and tenured generaion.
Tip: This exception message is thrown in the JVM if 98% of the time is used for GC and the available heap size is less than 2%.
Tip: The Heap Size does not exceed 80% of the available physical memory, generally the-XMS and-XMX options are set to the same, and the-XMX value of-xmn is 1/4.
Workaround: Manually set the heap size
Modify Tomcat_home/bin/catalina.sh
Add the following line to the "echo" Using catalina_base: $CATALINA _base "":
Java_opts= "-server-xms800m-xmx800m-xx:maxnewsize=256m"

example, the following gives a reference to the parameter setting of the Java JVM in the 1G memory environment:

Java_opts= "-server-xms800m-xmx800m-xx:permsize=64m-xx:maxnewsize=256m-xx:maxpermsize=128m-djava.awt.headless= True "

For Tomcat, if there are multiple applications under Tomcat, it is possible to put a common jar file under the Lib to the Tomcat Lib, and the release speed and speed are also improved.

Digression: Often see netizens complaining about the performance of tomcat than ..., instability, in fact, according to the author years of experience, from the "Connected star" to the current real estate portal network, we use Tomcat as a Web server, daily visits million, Tomcat still running well. Suggest that you have a problem more from their own procedures to start, read more about the Java Doc document.

Understanding of Java's PermGen concept, and how to deal with related problems