Java memory leak analysis and resolution

One, the problem arises
Project AdoptionTomcat6.0 for server, the database ismysql5.1, the database persistence layer ishibernate3.0, tospringMVC3.0 for Frames, after the completion of project development, on the eve of the stability of the machine, the test data is inserted4 article/S, update4 article/S, Access300 plays/S, smooth running speed, and it starts running slowly after three days., the number of visits reached1500W Times to throwJava Heap Space Ends.
Two
    1. Pre-analysis for connection pool memory overflow During the optimization of the connection pool parameters tomcat thread parameters     2. It seems that the problem is not a simple parameter configuration java garbage collection mechanism has a certain understanding The JVM's memory model is divided into Cenozoic and Laosheng generation ,jdk itself provides a monitoring tool jconsole.exe, into After the Bin folder is opened --tomcat--memory JVM Memory Recycling situation !--[If!supportlinebreaknewline]-->
!--[endif]--> /span>

As can be seen, each recovery of memory is less than the last time, you can judge the memory of Laosheng generation leaked.
3. Although it is known that there is a memory leak, but it is not possible to determine where the leak occurred, for this we need to export the heap (dump) for analysis, the JDK also provides the export tool Jvisualvm.exe, start right click on the thread-heap dump, you can export the dump file.
4. Using Mat (Memoryanalyzer) to analyze the dump file, the tool is: Http://www.eclipse.org/mat, can be downloaded offline version, can also be integrated into eclipse, easy to use. Open the tool to import the dump file, Wait a minute, and you'll be able to come up with the analyst report from Mat.

Mat points out that a HashMap instance of this dump has a memory leak , consumes jvm819m of memory , and continues clicking on details to get more detailed information.

This detail more detailed point out the problem is viewcache hashmap instances occupy a total of 859m memory 134w instance     5. Analyze the problem point , the code learned that the project uses SPRINGMVC, where viewcache is a view cache used in spring !--[If!supportlinebreaknewline]-->
!--[E ndif]-->

 LinkedList list = this  .getpathparam (    Mvvalue);  for  (int  i = 0; i < list.size (); I     ++ = = null  ;     Paramvalue  = requestutils.getparamstring (map, paramname); Paramvalue  = Paramvalue = = null ?     ": Paramvalue;   Mvvalue  = Stringutils.replace (Mvvalue, "#" + paramname+ "#"  return  new  Modelandview ( Mvvalue); 

Since Paramvalue is dynamically generated each time the UUID, resulting in a different mvvalue each time, so that each time a distinct view will be generated, such a view accumulated to more than 100 W, finally the Tomcat burst. A bit of Baidu, Sure enough, some people have noticed the problem: http://jackyrong.iteye.com/blog/1744342.
6. Once you know the problem, you can change the code, we need to fix the Modelandview view name, the dynamic parameters can be passed through the AddObject method provided by Modelandview, the modified code is as follows:

      //If the view name contains "snms_result.jsp", unify the return value of the view name to resolve the memory leak problem caused by the dynamic generation of the view name, by Feitianbubu May 27, 2013 11:21:31Modelandview mv=NewModelandview (Mvvalue); LinkedList list= This. Getpathparam (Mvvalue);  for(inti = 0; I < list.size (); i++) {String paramname=(String) list.get (i); String paramvalue=NULL; Paramvalue=requestutils.getparamstring (map, paramname); Paramvalue= Paramvalue = =NULL? "": paramvalue; Mv.addobject ("id", "," "+paramvalue+" "); }    returnmv

7. Code commit SVN, release the copy machine , observe the memory recycling situation

(GC is more frequent for faster simulation environments with 1000 times/s insert data and 1000 times/s to read data)
It can be seen that Laosheng memory is effectively recycled and memory leaks are resolved.

Java memory leak analysis and resolution