Java Memory leakage analysis (1)

Java Memory leakage

Article Source: http://hi.baidu.com/robin300/blog/item/467854df5ea692134954038c.html

Question proposal

An important advantage of Java is that the garbage collector (garbage collection, GC) automatically manages memory collection. programmers do not need to call functions to release the memory. Therefore, many Programmers think that Java does not have a memory leak problem, or that even memory leaks are not the responsibility of the program, but GC or JVM problems. In fact, this idea is incorrect, Because Java also has memory leakage, but its performance is different from that of C ++.

As more and more server programs use Java technology, such as JSP, Servlet, and EJB, server programs often run for a long time. In addition, in many embedded systems, the total amount of memory is very limited. The memory leakage problem becomes critical. Even if a small number of leaks are run each time, the system will also face the risk of crash after a long period of operation.

How Java manages memory

 

To determine whether memory leakage exists in Java, we must first understand how Java manages memory. Java memory management is the issue of object allocation and release. In Java, the programmer needs to apply for memory space for each object through the keyword new (except for the basic type), and all objects are allocated space in heap. In addition, the release of objects is determined and executed by GC. In Java, the memory allocation is completed by the program, and the memory release is completed by GC. This two-line approach indeed simplifies the programmer's work. But at the same time, it also increases the JVM's work. This is also one of the reasons for the slow Java program running speed. To release objects correctly, GC must monitor the running status of each object, including application, reference, reference, and assignment of objects. GC must monitor all objects.

The object state is monitored to release objects more accurately and timely. The fundamental principle of releasing an object is that the object is no longer referenced.

To better understand the working principle of GC, we can consider the object as the vertex of the directed graph, consider the reference relationship as the directed edge of the graph, and direct the directed edge from the quoter to the cited object. In addition, each thread object can be used as the starting vertex of a graph. For example, if most programs start to run from the main process, the graph is a root tree starting from the vertex of the main process. In this directed graph, the objects accessible to the root vertex are all valid objects, and GC will not recycle these objects. If an object (connected subgraph) is inaccessible to this root vertex (note that this graph is a directed graph), we think this (these) object is no longer referenced and can be recycled by GC.

The following example shows how to use a directed graph to represent memory management. For every moment of the program, we have a directed graph to indicate the memory allocation of the JVM. The right figure below shows that the program runs on the left to 6th rows.

Java uses Directed Graphs for memory management to eliminate the issue of reference loops. For example, if there are three objects that reference each other, as long as they are inaccessible to the root process, GC can also recycle them. The advantage of this method is that the memory management accuracy is high, but the efficiency is low. Another common memory management technology is the use of counters. For example, the com model uses counters to manage components. Compared with Directed Graphs, it has low precision rows (it is difficult to handle the issue of circular references ), however, the execution efficiency is high.

What is memory leakage in Java?

 

Next, we can describe what is memory leakage. In Java, memory leakage is the existence of some allocated objects. These objects have the following two features: first, these objects are reachable, that is, in a directed graph, there are paths that can be connected to them; second, these objects are useless, that is, they will not be used by the program in the future. If the memory leakage in the zookeeper reef is removed from zookeeper Ava, these objects will not be recycled by GC, but it will occupy the memory.

In C ++, the memory leakage scope is larger. Some objects are allocated with memory space but cannot be accessed. Because c ++ does not have GC, these memories will never be recovered. In Java, GC is responsible for the collection of these inaccessible objects, so programmers do not need to consider the memory leakage.

Through analysis, we know that for C ++, programmers need to manage edges and vertices themselves, while Java programmers only need to manage edges (no need to manage the release of vertices ). In this way, Java improves programming efficiency.

Therefore, through the above analysis, we know that memory leakage also exists in Java, but the range is smaller than that in C ++. Because Java ensures that all objects are reachable, and all unreachable objects are managed by GC.

For programmers, GC is basically transparent and invisible. Although only a few functions can access GC, for example, the system. GC () function that runs GC, according to Java language specification definition, this function does not guarantee that the JVM garbage collector will certainly execute. Because different JVM implementers may use different algorithms to manage GC. Generally, the priority of GC threads is low. There are also many strategies for JVM to call GC, some of which start to work only when the memory usage reaches a certain level, some also start to run regularly, and some are gentle execution of GC, some are interrupted GC execution. But in general, we don't need to care about this. Unless in some specific scenarios, GC execution affects the performance of applications, such as web-based real-time systems, such as online games, if you do not want the GC to suddenly interrupt application execution and perform garbage collection, you need to adjust the GC parameters so that the GC can release the memory in a gentle manner, for example, if garbage collection is divided into a series of small steps for execution, sun's hotspot JVM supports this feature.

The following is a simple example of Memory leakage. In this example, we cyclically apply for an object and put the applied object into a vector. If we only release the reference, the vector still references the object, therefore, this object cannot be recycled for GC. Therefore, if an object is added to a vector, it must be deleted from the vector. The simplest way is to set the vector object to null.

Vector v=new Vector(10); for (int i=1;i<100; i++) { Object o=new Object(); v.add(o); o=null; }

// At this time, all object objects are not released because variable v references these objects.

How to detect memory leakage

 

The last important issue is how to detect Java memory leaks. Currently, we usually use some tools to check the memory leakage of Java programs. There are already several professional Java memory leak check tools on the market. Their basic working principles are similar. They are all through monitoring the application, release, and other actions of all objects when Java programs are running, collects, analyzes, and visualizes all memory management information. Based on this information, developers will determine whether the program has a memory leakage problem. These tools include optimizeit profiler, Jprobe Profiler, jinsight, and purify from rational.

Next, we will briefly introduce the basic functions and working principles of optimizeit.

Optimizeit profiler version 4.11 supports four types of applications: application, applet, Servlet, and romote application, and supports most types of JVM, including Sun JDK series and ibm jdk series, and JBuilder's JVM. In addition, the software is written in Java, so it supports multiple operating systems. The optimizeit series also includes two tools: thread debugger and code coverage, which are used to monitor the thread status and code coverage during running.

After all the parameters are set, we can run the tested program in the optimizeit environment. During the program running, optimizeit can monitor the memory usage curve (for example ), the size of the heap applied by the JVM and the actual memory used. In addition, during the running process, we can pause the running of the program at any time, or even forcibly call the GC, so that the GC can perform memory return. Through the memory usage curve, we can understand the memory usage of the program as a whole. This kind of monitoring is necessary for long-running applications, and it is easy to detect memory leaks.

During the running process, we can also view the memory usage from different perspectives. optimizeit provides four methods:

• Heap view. This is a comprehensive perspective. We can understand all the object information (quantity and type) in the heap and perform statistics, sorting, and filtering. Understand the changes of related objects.
• Method perspective. From the method perspective, we can know the methods in which each type of objects are allocated and their quantity.
• Object perspective. Given an object, from the object perspective, we can display all its reference and reference objects. We can understand all the reference relationships of this object.
• Reference graph. Given a root, we can use the reference graph to display all the output references starting from this vertex.

During the running process, we can observe the memory usage at any time. In this way, we can quickly find objects that are not released for a long time and are no longer in use. We check the lifetime of these objects to see if they are memory leaks. In practice, it is very troublesome to look for memory leaks. It requires programmers to be clear about the code of the entire program and rich debugging experience, however, this process is very important to many key Java programs.

To sum up, Java also has memory leakage problems, mainly because some objects are not used, but they are still referenced. To solve these problems, we can use software tools to check for memory leaks. the main principle of the check is to expose all objects in the heap, so that programmers can find useless objects that are still referenced.