Handling memory vulnerabilities in the Java program (below)
When research should focus on how to prevent memory leaks and memory leaks (Author: Transfer from IBM DeveloperWorks Jim Patrick, 2001 at 11:40 on April 12)
Below I will explain how I use Sitraka Software JPRobedeBugger to detect and remove memory vulnerabilities to make it aware of the process of deployment of these tools and the process required to successfully remove vulnerabilities. One example of memory vulnerability is discussed to discuss a problem, and our department is developing a commercial release software. This is a Java JDK 1.1.8 application. A tester spent a few hours to study this program eventually make this problem. It is displayed. The basic code and packages of this Java application are developed by several different development teams at different times. I suspect that memory vulnerabilities in the app are caused by programmers who do not really understand the code developed by others. The Java code we are discussing allows users to create applications for Palm Personal Digital Assistant, without having to write any Palm OS local code. By using a graphical user interface, the user can create a form, add a control to the form, and then connect the events of these controls to create a PALM application. Test persons found that this Java application will eventually exhaust memory with continuous creation and deletion of forms and controls. Developers did not detect this problem because their machine has more physical memory. In order to study this problem, I used JProbe to determine what is wrong. Despite the powerful tools and memory snapshots provided by Jprobe, the study is still a lengthy, continuously repeated process, first to determine the cause of the memory vulnerability, then modify the code, and finally test the results. Jprobe offers several options to control which information actually records during debugging. After several tests, I conclude that the most effective way to get the required information is to close the performance data collection, and focus on the captured stack data. Jprobe provides a view called Runtime Heap Summary that displays the memory of the heap occupied by the Java application runtime. It also provides a toolbar button, which can force JVM to perform garbage collection if necessary. If you try to figure out, this instance will not be collected as garbage when Java applications no longer need a given class instance. This feature will be useful. Figure 2 shows the change in the use of the stack reserves over time. Figure 2. Runtime Heap Summary In Heap Usage Chart, the blue part indicates that the assigned stack space is sized. After starting this Java program and reaches a steady state, I force the garbage collector to run, the performance in the figure is the sudden drop of the blue line on the left side of the left side. Subsequently, I added four forms, then deleted them and called the garbage collector again. When the program returns the initial state of only one visual form, the blue area before the checkpoint is higher than the checkpoint, indicating that there may be memory vulnerabilities. I have a vulnerability by looking at Instance Summary, because instance summary indicates that the count of the FormFrame class (which is the main user interface class of the form) increases 4 after the checkpoint. Finding Cause In order to remove the problem reported by the tester, the first step I take is to find a few simple, repeatable test cases. For this reason, I found that I only have to add a form, delete it, then force garbage collection, resulting in many class instances associated with the deleted form remain active. This problem is obvious in JProbe's Instance Summary view, this view counts the number of instances per java class in the heap.
In order to identify those references that make the garbage collector do not work properly, I use JProbe's Reference Graph (shown in Figure 3) to determine which classes still reference the FormFrame class currently unselected. This process is one of the most complex processes when debugging this issue, because I have found that many different objects still reference this useless object. Used to identify which reference is truly caused by the test error process of this problem. In this example, a root class (the type in the upper left corner) is the origin of the problem. On the right, the blue highlighted class is tracked from the initial FormFrame class. Figure 3. In this case, in this case, in this case, in this case, in this case, finally, the culprit is to include a static HashTable font manager class. By reverse tracking the list of references, I found that the root node is used to store a static HashTable in the font used for each form. Each form can be enlarged or narrowed separately, so this hashtable contains a Vector of all fonts with a given form. When the size of the form changes, this font vector is extracted, and the appropriate scaling factor is applied to the font size. The problem with this font manager class is that although the program stores the font vector in this HashTable when the program is created, but does not provide the code that deletes the vector when deleting the form. Therefore, this static HashTable (existing in the survival of the application) will never delete those keys that reference each form. As a result, the form and all the associated classes are idle in memory. A simple solution for correcting this issue is to add a method to the font manager class to call the HashTable Remove () method when the user is deleted. removeKeyFromHashtables () method as follows: public void removeKeyFromHashtables (GraphCanvas graph) {if (! graph = null) {viewFontTable.remove (graph); // // delete the hashtable keys to prevent a memory leak}} Then, I A call to this method is added to the FormFrame class. FormFrame is actually using Swing's internal framework to implement the form user interface, so I will add the call to the font manager to the method called when the internal framework is completely closed, as shown below: / ** * When removed (Dispose) FormFrame is called. Clear references to prevent internal vulnerabilities. * / Public void inframeclosed (InternalFrameEvent E) {fontManager.get (); canvas; canvas = null; setDesktopicon (null);} After these modifications, I use debugger confirmation: When performing the same test case When the object count associated with the deleted form is reduced. Preventing internal vulnerabilities can prevent internal vulnerabilities by observing certain common problems. The Collection class (such as HashTable and Vector) is often a place where memory vulnerability occurs. This class is declared with a Static keyword and is especially like this in the entire survival of the application. Another common problem is that you register a class as an event listener, and there is no revocation when you no longer need this class. In addition, you often need to set the class member variable points to other classes to NULL when appropriate.
The reason for the small knot looks for memory vulnerabilities may be a bored process, not to mention the need for a dedicated debugging tool. However, once you are familiar with these tools, you can find memory vulnerabilities when you search for these tools and search when tracking object references. In addition, you will also explore some valuable techniques that not only help to save project costs, but also enable you to understand which coding methods should be avoided in future projects. Resources Before you begin to find memory leaks, familiarize yourself with one of the following Debugger: ● Sitraka Software's JProbe Profiler withMemory Debugger ● Jinsight on Intuitive System of Optimizeit Java Performance Profiler ● Paul Moeller of Win32Java Heap Inspector ● IBM alphaWorks Web site Jinsight: A Tool for Visualizing The Execution Of Java Program (DeveloperWorks, November 1999) Detailed explanation how this utility helps you analyze performance and debug code. Note: The project discussed in this article is done with JDK 1.1.8, but JDK 1.2 introduces a new package, java.lang.ref, this package can interact with the garbage collector. In addition, JDK 1.2 has also introduced a Java.util.weakhashMap class that can be used instead of traditional Java.util.HashTable classes. This class does not block the garbage collector recycling key object. JDK 1.3 Solaris, Linux and Microsoft Windows version are introduced
Java Hotspot Client VM, which has a new, improved garbage collector. About the author Jim Patrick is an adviser programmer for IBM Pervasive Computing Division. He has written procedures with Java since 1996. Please contact JIM by patrickj@us.ibm.com. Full text | Previous
