Java Simple memory leak analysis and resolution

First, the problem arises
The project uses Tomcat6.0 as the server, the database is mysql5.1, the database persistence layer is hibernate3.0, takes the springMVC3.0 as the framework, after the project development completes, the line Eve carries on the stability to copy the machine, the test data is inserts 4 strips/s, updates 4 strips/s, Access 300 times/S, the pre-run speed is smooth, three days after the start of slow, traffic reached 1500W times to throw Java heap space end.
Second, the problem analysis
1. Pre-analysis for connection pool memory overflow, during the optimization of the connection pool parameters, tuning the tomcat thread parameters, replace the database connection pool, the problem is still
2. It seems that the problem is not a simple parameter configuration, need a little in-depth research and analysis, and colleagues in the study of some information, Java garbage collection mechanism has a certain understanding, the JVM's memory model is divided into Cenozoic and Laosheng generation, the JDK itself provides a monitoring tool jconsole.exe, After entering the Bin folder to open, choose to connect--tomcat--memory, you can start to monitor the JVM memory recycling situation, after a period of monitoring, found that the Laosheng generation of memory recovery exists exception.

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 moment, 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 points to the problem, a HashMap instance called Viewcache occupies a total of 859M of memory, although each instance has only hundreds of bytes, but altogether produces 134W instances.
5. Analyze the problem, then the problem is to troubleshoot the code, the Code learned that the project uses SPRINGMVC, where Viewcache is a view cache used in spring, in the project such as a processing view jump code:
LinkedList list = This.getpathparam (Mvvalue);
for (int i = 0; i < list.size (); i++) {
String paramname = (string) list.get (i);
String paramvalue = null;
Paramvalue = requestutils.getparamstring (map, paramname);
Paramvalue = Paramvalue = = null? "": paramvalue;
Mvvalue = Stringutils.replace (Mvvalue, "#" + paramname+ "#", Paramvalue);
}
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:
Modelandview mv=new Modelandview (mvvalue);
LinkedList list = This.getpathparam (Mvvalue);
for (int i = 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+");
}
return MV;
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 Simple memory leak analysis and resolution