Shulou(Shulou.com)06/01 Report--

What this article shares with you is an example analysis of Tomcat and memory leak handling. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

However, with the growth of development experience, the increase of applications that have been developed, and the increase of class to be loaded in applications, memory overflows (OOM) are often encountered. Or, more specifically, the memory overflow caused by the increase in class loading is java.lang.OutOfMemoryError: PermGen space

At this point, the solution to OOM is generally

To analyze whether there is something wrong with the code written in the application, you can use some tools to observe the types of class that take up a lot of memory in the application (such as analyzing the amorous ring of Java 7 weapon series through JVisualVM-the multi-function Profiling tool JVisualVM, or through MAT).

Modify the JVM startup parameters to increase the configuration for Perm Gen.

In an application server such as Tomcat, because it runs as an application container, it may not take up much of its own Perm Gen, but it needs to consider the occupation of applications deployed to the container. Some applications rely on a large number of third-party class libraries, and some applications will dynamically generate a large number of class at run time. The loading of these contents can easily lead to the OOM of Perm Gen.

For OOM processing, a small chunk of memory is used internally at startup and released for temporary relief when OOM is generated, which is called oomParachute. I wrote an introduction earlier (this is what OOM,Tomcat prevention does).

In addition, Tomcat also provides the ability to find memory leaks in manager applications.

The figure shows clearly that this function is mainly used to analyze whether memory leaks are caused when the application is stopped, redeployed, and undeployed.

After the request, the information display area above the manager will indicate whether there is a memory leak caused by the application.

It is important to note, however, that this feature triggers an Full GC execution, and the code uses System.gc (), which needs to be used with caution in a production environment.

So, under what circumstances can it lead to so-called application memory leaks?

As we all know, in order to achieve class isolation between applications, Tomcat uses a separate WebappClassLoader for each application, so that even if multiple applications use different versions of the same class library, they will not conflict with each other. (refer to the previous article: Tomcat classloader and class isolation and sharing between applications, classloader and class conflict)

However, in this case, when an application has performed a stop operation or a redeploy operation, a new classLoader is generated to load the newly deployed application class information.

We know that in Java, there is a reference relationship between classes, similar to strong references, weak references, phantom references, which are used to recycle some unwanted class during GC to make room. In theory, the previous classLoader should have been garbage collected, but sometimes, due to the previous reference of some classes, the classLoader and a series of class files loaded by it cannot be identified as garbage. At this time, these class still reside in Perm Gen. As the application is started and stopped many times and redeployed many times, the OOM of Perm Gen appears.

Generally speaking, the use of the following class libraries can easily cause class loader to escape garbage collection and cause memory leaks:

JDBC driver registration

Some logging frameworks

Use of ThreadLocal that is not removed

Unstopped Thread

In addition, the use of some Java API can easily lead to this problem, such as

Javax.imageio API

XML parsing

RMI usage

Because these classLoader are easy to occupy, they can not be recycled. If these class are handed over to the class loader of each application to load, there will be more and more of these classes in the Perm Gen, resulting in leakage.

To this end, the JreMemoryLeakPreventionListener component is introduced into Tomcat. The idea is to load these classes through System class Loader when Tomcat starts. Because of the loading principle of the classloader (the default parent takes precedence, and the classes of these systems are delegated to the system classloader for loading), these classes will no longer be reloaded by WebclassLoader, thus reducing memory leaks.

This component is enabled by default in Tomcat's configuration server.xml, so you are already using these features unwittingly.

The above is an example analysis of Tomcat and memory leak handling. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please 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.