Expert interview: Tomcat 7 Memory leakage protection

BKJIA reported "Tomcat 7 RC4 release" for the first time this morning. Tomcat 7 Memory leakage protection has always been a concern. At the beginning of this year, the DZone website interviewed Mark Thomas about Tomcat 7's memory leakage protection function. Mark Thomas is the chief software engineer of SpringSource, it is also the head of Tomcat code submission.

A new function is introduced in Tomcat 7: Memory leakage protection. This function can solve the problems that many Web applications may cause memory leakage, especially when the application is reloaded.

The following is the content of the specific interview (the level is limited and the content has been simplified a lot. For details, see the English version ):

DZone: What causes memory leakage when Web applications are reloaded? How is this memory leakage?

Mark Thomas: the most direct phenomenon is that PermGen generates an OutOfMemoryError and Tomcat fails.

PermGen space stands for Permanent Generation space, which refers to the Permanent storage area of the memory. If your web app uses a large number of third-party jar files, the error message is generated when the jvm size exceeds the default jvm size (4 MB.

To prevent this problem, make sure that the web application classloader does not save any object references during the overload.

DZone: Please tell us about the memory leakage problem during the previous heavy load of Tomcat.

Mark Thomas: this problem of Tomcat has existed until I joined this project.

DZone: Have all the bugs that cause memory leakage in Tomcat been fixed?

Mark Thomas: it should be said that all the problems we know have been solved, and there may be some unknown problems.

 
Tomcat virtual machine memory Analysis

 

DZone: library,JavaWhat are the usage bugs of APIs that may cause memory leakage?

Mark Thomas: Memory leakage has the same cause. For example, if you initialize an object in the ClassLoader of a Web application, the object will save its reference to an instance or Registry, when this object is revoked from the ClassLoader during overload, the Registry references the object, which will cause memory leakage.

Generally, the library may have memory leaks:

1. JDBC driver registration

2. Some log frameworks

3. Save the object in ThreadLocal, but do not delete it.

4. Started the thread but did not stop it.

The memory leakage of Java APIs includes:

1. Use javax. imageio API (the Google Web Toolkit can trigger this)

2. Use java. beans. Introspector. flushCaches () (Tomcat does this to prevent memory leaks caused by this caching)

3. Use the XML Parser (the root cause is unknown due to a bug in the JRE)

4. Use RMI remote method call (somewhat ironically, causes a leak related to the garbage collector)

5. Read resources from Jar files

DZone: Tell us how Tomcat 7 handles these problems.

Mark Thomas: the key to the problem lies in the clearReferences () method of the WebappClassLoader class of Tomcat 7.

For problems in the previously mentioned Java APIs, ensure that the Tomcat core uses these APIs for the first time and then let the application call them to prevent memory leakage. For how to protect memory leakage, see JreLeakPreventionListener class.

DZone: In your opinion, how much is Tomcat 7 better than Tomcat in the current version in terms of Memory leakage control?

Mark Thomas: there has been a significant improvement.

DZone: What is the development progress of Tomcat 7? Is there an exact release date?

Mark Thomas: Tomcat 7 is developing very smoothly. JSP and EL 2.2 specifications have been implemented, and Servlet 3.0 specifications are nearing completion.

DZone: What else do you want to add about Tomcat 7?