Register the introspectorcleanuplistener listener in Web. XML to solve the memory leakage problem caused by struts and other frameworks.

You can add the following methods:

 
<Listener> <listener-class> org. springframework. Web. util. introspectorcleanuplistener </listener-class> </listener>
 

Org. springframework. Web. util. introspectorcleanuplistenerSource codeThe explanation is 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.

For Web ApplicationsProgramWhen disabled, introspectorcleanuplistener will refresh the introspector cache of JDK JavaBeans. Register this listener in your web. xml file to ensure that the class loader of the Web application and its loaded classes release resources correctly.

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 holds a hard reference to these classes. Therefore, the class loaders of these classes and Web applications will not be reclaimed by the garbage collector when the web application is closed! Introspectorcleanuplistener cleans it appropriately and enables it to 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 refresh the entire introspector cache, and there is no other way to specify the class referenced by the application. This will delete the introspector results cached by all other applications 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 shocould 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.

Note that you do not need to use this listener when using spring's internal bean mechanism, because spring's introspection results cache will immediately refresh the analyzed JavaBeans introspector cache, instead, it will only hold a cache in the application's classloader. Although spring itself does not leak, note that even if the Spring framework class itself resides in a "common" Class Loader (such as the system classloader, you should also use introspectorcleanuplistener. In this case, this 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
Introspector: e.g. Struts and quartz.

Application class, almost no need to directly use JavaBeans introspector, so usually not the introspector resource causes memory leakage. On the contrary, many libraries and frameworks do not clean up 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 prevent the class loaders of the entire web application from being recycled! The result is that when the web application is closed, all static class resources (such as single instance objects) of the application are not released. The root cause of Memory leakage is not these unrecycled classes!

This listener shoshould 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. 

Introspectorcleanuplistener should be registered as web. the first listener in XML is registered before any other listener, for example, before spring's contextloaderlistener is registered, the introspectorcleanuplistener takes effect properly in the Web application lifecycle.