Org. springframework. web. servlet. view. InternalResourceViewResolver Memory leakage problem, resourceview
Spring uses org. springframework. web. servlet. view. InternalResourceViewResolver Memory leakage
With Eclipse Memory Analyzer (http://www.eclipse.org/mat/) analysis tools, 50.51% in heap Memory is produced by InternalResourceViewResolver.
The current Spring version I use is Spring 3.1.1.RELEASE.
One instance"Org. springframework. web. servlet. view. InternalResourceViewResolver"Loaded"Org. apache. catalina. loader. WebappClassLoader @ 0x6e0024ca0"Occupies2,342,803,136 (50.51%)Bytes. The memory is accumulated in one instance"Java. util. HashMap $ Entry []"Loaded"<System class loader>".
Keywords
Org. springframework. web. servlet. view. InternalResourceViewResolver
Java. util. HashMap $ Entry []
Org. apache. catalina. loader. WebappClassLoader @ 0x6e0024ca0
After monitoring the online services, it is found that the system has undergone many full gc operations. Why can't frequent Full GC operations be recycled; the reason is that a large number of surviving objects hold a strong reference relationship to HashMap.
The JVM Memory Object recycling policy is analyzed by gc root accessibility. When an object fails after GC Root, it indicates that the object has been dead and can be recycled next time.
Next, let's analyze the cause from the code.
# If I want to be a JAVA student, do you feel familiar with the following code? Do you think there is no problem from this method alone .....
@ RequestMapping (value = "/index. do ", params =" userId ") public ModelAndView index (String userId, ModelAndView mv) {// TODO business processing... mv. setViewName ("redirect:/your_uri.do? UserId = "+ userId); return mv ;}
Let's take a look at how Spring processes the returned redirection.
In InternalResourceViewResolver, the parent class AbstractCachingViewResolver
public View resolveViewName(String viewName, Locale locale) throws Exception { if (!isCache()) { return createView(viewName, locale); } else { Object cacheKey = getCacheKey(viewName, locale); synchronized (this.viewCache) { View view = this.viewCache.get(cacheKey); if (view == null && (!this.cacheUnresolved || !this.viewCache.containsKey(cacheKey))) { // Ask the subclass to create the View object. view = createView(viewName, locale); if (view != null || this.cacheUnresolved) { this.viewCache.put(cacheKey, view); if (logger.isTraceEnabled()) { logger.trace("Cached view [" + cacheKey + "]"); } } } return view; } } }
Here, Spring uses viewName + locale as the Cache key to Cache the created View to HashMap, so as to avoid re-creating the View each time. The following is the source code of the Spring viewCache instance object.
/** Map from view key to View instance */ private final Map<Object, View> viewCache = new HashMap<Object, View>();
Because the URI of the return ModelAndView object contains dynamic parameters, the Uris returned by each user are different. As a result, the Cache Key cannot be hit, and a large number of views are created and cached to viewCache.
"redirect:/your_uri.do?userId="+userId
If you want to use Spring redirection, we recommend that you use RedirectView. For example:
@ RequestMapping (value = "/index. do ", params =" userId ") public RedirectView index (RedirectView mv, String userId) {// TODO Service Processing UriComponentsBuilder builder = UriComponentsBuilder. fromPath ("/xxx. do "); builder. queryParam ("userID", userId); mv. setUrl (builder. build (). encode (). toUriString (); return mv ;}