Identify the culprit for Java program Memory overflow

I once did a small swing in the beginning of the process, using the Java Se,swing,thread and other Dongdong, the original experience has not done a rigorous performance testing, cloth to the production environment after a period of time to find that the small program will sometimes throw The java.lang.OutofMemoryError exception is the Java memory overflow. There was a lot of information on the Internet, tried some methods, the code has a little bit of optimization, but there is a problem I still can not find the solution-I do not know why the Java garbage collection mechanism can not reclaim its resources after the child form is closed, because this Java program may have to switch some subforms frequently, Then these subforms closed after the failure to release resources caused the Java program OutOfMemoryError potential pitfalls!

Recently inadvertently on the Internet to see a monitoring Java Program memory Use tool-jprobe, immediately recall that about the memory overflow problem, so I downloaded JProbe8.0.0 want to start from the analysis of memory to find the answer I want. After the software has been downloaded and installed, the detailed user's guide in the installation directory (people who know the software and English will soon be able to get started) is mainly two steps:

1. Use the Jprobe Config tool to generate J2SE or Java program Control scripts (a. jpl file and a. bat file) on the command line, enter the directory where the. bat file resides, and then execute the batch to run the Java program to be monitored

2. Run Jprobe console tool, click "Attach to Session ..." button, pop-up Java program Memory Real-time monitor chart "Runtime Summary", we mainly look at "Data" The contents of the card (note: The first time you use the software may encounter some minor problems: such as the program published as a jar package if the runtime will read the configuration file, starting from the control script, the configuration file can not find the exception, the solution is: do not hit the jar package, directly on the folder to publish and possibly because some anti-virus software's network firewall causes jprobe not to be able to connect to the control script the session, causes the monitor chart to be unable to open, the solution is: cancels the firewall to the Jprobe Access network restriction)

The Real-time monitor chart "Runtime Summary" is shown in the following illustration:

You can set the package or class to monitor, and then click the "Refresh Runtime Data" button to refresh the memory of these objects, when you think that a class is more suspicious, you can continue to use the program in the process of monitoring its lifecycle, see if it is like the pre Period, the memory occupied after the end of the lifecycle is released. As we all know: Java memory recycling is done automatically, no programmer intervention, we call it garbage collection, this garbage collection may be irregular, that is, when the program consumes less memory resources may be the JVM's garbage collection frequency is relatively low, whereas Java programs consume more memory resources , the frequency and intensity of garbage collection is relatively high, this kind of garbage collection uncertainty is likely to affect our judgment, but we can click on the Jprobe monitoring interface on the top right of "Request a garbage Collection" (Like a Trash Can icon) button to send a garbage collection request to the JVM, wait a few seconds and then click "Refresh Runtime Data", and this time if the class name of the object that is expected to have been destroyed is still not The class column at the bottom of the monitoring screen disappears or the number of objects is not reduced (please try it a few more times to make sure that the JVM does perform garbage collection), and congratulations! 90% probability you've found a flaw in the program

The process of finding the culprit may be time-consuming and a challenge to the programmer's patience. I stayed up all night, Kung fu not negative, basically put my small program of all the memory overflow vulnerabilities are found and made up. The truth tells me that before that subform. The root cause of the resource being unable to be freed after the form is closed is that the subform invokes the Dispose () method, but the reference to the subform object is always: either by a static HashMap reference, or because its internal child thread class is not freed, Or it's an event listening class is not released (borrow Jprobe's eyes a test, found that the problem is really a lot of Ah!) So we have to completely release an object. The key to taking resources is to find and release all references to it!