The increase method is as follows:
- <listener>
- <listener-class>
- org.springframework.web.util.IntrospectorCleanupListener
- </listener-class>
- </listener>
It is explained in the source code of org.springframework.web.util.IntrospectorCleanupListener as follows:
Listener that flushes the JDK's JavaBeans Introspector cache on web app shutdown. Register this listener in your web.xml to guarantee proper release of the web application class loader and its loaded classes.
The IntrospectorCleanupListener will flush the JDK's JavaBeans Introspector cache when the web application is shut down. Register this listener in your web.xml to ensure that the web application's class loader and the classes it loads properly release resources.
If the JavaBeans Introspector has been used to analyze application classes, the system-level Introspector cache will hold a hard reference to those classes. Consequently, those classes and the web application class loader will not be garbage-collected on web app shutdown! This listener performs proper cleanup, to allow for garbage collection to take effect.
If the JavaBeans Introspector has been used to analyze application classes, the system-level Introspector cache will hold a hard reference to these classes. Therefore, these classes and the web application's classloader will not be collected by the garbage collector when the web application shuts down! The IntrospectorCleanupListener will properly clean it up so that it can be recycled by the garbage collector.
Unfortunately, the only way to clean up the Introspector is to flush the entire cache, as there is no way to specifically determine the application's classes referenced there. This will remove cached introspection results for all other applications in the server too.
Unfortunately, the only way to clean up the Introspector is to flush the entire Introspector cache, there is no other way to specify exactly what classes the application is referencing. This will delete all other applications' cached Introspector results on the server.
Note that this listener is not necessary when using Spring's beans infrastructure within the application, as Spring's own introspection results cache will immediately flush an analyzed class from the JavaBeans Introspector cache and only hold a cache within the application's own ClassLoader. Although Spring itself does not create JDK Introspector leaks, note that this listener should nevertheless be used in scenarios where the Spring framework classes themselves reside in a 'common' ClassLoader (such as the system ClassLoader). In such a scenario, this listener will properly clean up Spring's introspection cache.
Please note that when using Spring's internal bean mechanism, you do not need to use this listener, because Spring's own introspection results cache will immediately refresh the analyzed JavaBeans Introspector cache, but only hold it in the application's own ClassLoader a cache. While Spring itself does not produce leaks, be aware that the use of the IntrospectorCleanupListener should still be used even in cases where the Spring Framework classes themselves reside in a "common" classloader (such as the system's ClassLoader). In this case, the IntrospectorCleanupListener will properly clean up Spring's introspection cache.
Application classes hardly ever need to use the JavaBeans Introspector directly, so are normally not the cause of Introspector resource leaks. Rather, many libraries and frameworks do not clean up the Introspector: e.g. Struts and Quartz.
Application classes rarely need to use the JavaBeans Introspector directly, so it is usually not the Introspector resource that causes memory leaks. Conversely, many libraries and frameworks do not clean the Introspector, such as: Struts and Quartz.
Note that a single such Introspector leak will cause the entire web app class loader to not get garbage collected! This has the consequence that you will see all the application's static class resources (like singletons) around after web app shutdown, which is not the fault of those classes!
Note that a simple Introspector leak will cause the entire web application's classloader to not be recycled! The result of this will be that when the web application closes, all the application's static class resources (such as: single-instance objects) are not released. The root cause of the memory leak is not actually these unreclaimed classes!
This listener should be registered as the first one in web.xml, before any application listeners such as Spring's ContextLoaderListener. This allows the listener to take full effect at the right time of the lifecycle.
The IntrospectorCleanupListener should be registered as the first Listener in web.xml, before any other Listeners, such as Spring's ContextLoaderListener, to ensure that the IntrospectorCleanupListener takes effect at the appropriate time in the web application's lifecycle.
Summarize:<!--web.xml-->
<listener> <listener-class>org.springframework.web.util.IntrospectorCleanupListener</listener-class> </listener>
1. This listener is mainly used to solve the problem of memory leak caused by java.beans.Introspector
2. This listener should be registered as the first Listener in web.xml, and registered before any other Listeners, such as Spring's ContextLoaderListener, to ensure that the IntrospectorCleanupListener takes effect at the appropriate time in the web application's life cycle. 3. The purpose of the java.beans.Introspector class in JDK is to find out whether the Java class conforms to the JavaBean specification. If some frameworks or programs use the Introspector class, a system-level cache will be enabled, which will store some previously loaded and A reference to the parsed JavaBean. When the Web server is shut down, because the reference of these JavaBeans is stored in the cache, the garbage collector cannot recycle the JavaBean objects in the Web container, and finally the memory becomes larger. And org.springframework.web.util.IntrospectorCleanupListener is an auxiliary class specially used to deal with Introspector memory leaks. The IntrospectorCleanupListener will clean the Introspector cache when the web server is stopped, so that those Javabeans can be properly collected by the garbage collector. Spring itself will not have this problem, because Spring will refresh the JavaBeans Introspector cache immediately after loading and analyzing a class , which ensures that this memory leak problem will not occur in Spring. But some programs and frameworks do not clean up after using JavaBeans Introspector (such as Quartz, Struts), which eventually leads to memory leaks.