Tomcat 6.x Perm Memory leakage, 6. xperm

Tomcat 6.x Perm Memory leakage, 6. xperm
Tomcat 6.x
The last modification time of JSP files exceeds the current system time, leading to Memory leakage in the Perm zone (java Memory pool CMS Perm Gen)

Scenario:
Because the Test Service needs to simulate cross-day testing, the server implementation is usually modified to complete the test service. After the test is completed, the system time is not synchronized immediately, but is directly released and launched, the problem arises. Because the traversal time is used for packaging, the last modification time of all packaged files is crossed.
For example, today is: 2015.1.1. in order to complete the test, the system time is crossed to 2015.1.5. At this time, the last modification time of all files packaged is no.

This was originally just a traversal of the last modification time of the file. Because Tomcat supports the hot Release Feature of JSP, changes to the JSP file will be detected every 4 seconds, because the last modification time of the JSP file exceeds several days after the current system time, Tomcat will re-trigger the hot release every 4 s (Tomcat hot release delay time) in these days, to put it bluntly, the custom Class loading mechanism is used to re-load the Class. Because JDK1.6 Class info exists in the Perm zone, the memory recovery in this region is extremely demanding, this causes a large number of new classes to be loaded, resulting in memory overflow in the Perm area.

The modification method is to synchronize the Time of the Publishing Server.
This problem has been fixed in Tomcat 7.
Locate the Class load problem. You can add the JVM parameter-XX: + TraceClassLoading-XX: + TraceClassUnloading at Tomcat startup.

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.