Detailed memory leaks in the Java language and how to detect problems

An important advantage of Java is the automatic management of memory recycling through the garbage collector (garbage COLLECTION,GC), where programmers do not need to invoke functions to free up memory. As a result, many programmers think that Java does not have a memory leak problem, or that even a memory leak is not the responsibility of the program, but a GC or JVM problem. In fact, this is not true, because Java also has memory leaks, but it behaves in a different way than C + +.

As more and more server programs adopt Java technologies, such as Jsp,servlet, EJB, and so on, server programs tend to run for long periods of time. In addition, in many embedded systems, the total amount of memory is very limited. Memory leaks are also critical, and the system is at risk of collapsing even after running a small amount of leaks for a long time.

How Java manages memory

To determine whether there is a memory leak in Java, we must first understand how Java manages memory. Java's memory management is the issue of object allocation and deallocation. In Java, programmers need to request memory space for each object with the keyword new (except for the base type), and all objects allocate space in the heap (Heap). In addition, the release of objects is determined and executed by GC. In Java, the allocation of memory is done by the program, and the release of memory is a GC, and the two-line method does simplify the programmer's work. But at the same time, it also aggravates the work of the JVM. This is one of the reasons why Java programs run slower. Because, in order to properly release the object, the GC must monitor the running state of each object, including the object's application, reference, reference, assignment, and so on, which the GC needs to monitor.

Monitoring object state is to release objects more accurately and in a timely manner, and the fundamental principle of releasing objects 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 a directed graph, consider the reference relation as a directed edge of the graph, and point to the referenced object from the reference. In addition, each thread object can be the starting vertex of a graph, for example, most programs start with the main process, and the graph is a root tree that starts with the vertex of the main process. In this graph, the objects to which the root vertex can reach are valid objects, and the GC will not recycle them. If an object (connected subgraph) is not reached with this root vertex, then we think that the object is no longer referenced and can be recycled by GC.

Below, we give an example of how to represent memory management with a graph. For every moment of the program, we have a graph that represents the memory allocation of the JVM. The following is the illustration of the left program running to line 6th.

Java uses a graph-like approach to memory management that eliminates the problem of reference loops, such as having three objects that reference each other, so that GC can recycle them as long as they are not up to the root process. The advantage of this approach is that it is highly accurate to manage memory, but less efficient. Another commonly used memory management technology is to use counters, such as the COM model using counter method to manage the component, which is less accurate than the graph, the precision is difficult to deal with the problem of circular reference, but execution is very efficient.

What is a memory leak in Java

Below, we can describe what a memory leak is. In Java, a memory leak is the existence of some allocated objects that have the following two characteristics, first of all, these objects are accessible, that is, in the direction graph, the existence of the path can be connected to, and secondly, these objects are useless, that the program will not use these objects later. If the objects meet these two conditions, they can be judged as memory leaks in Java, which are not reclaimed by GC, but they occupy memory.

In C + +, memory leaks are larger in scope. Some objects are allocated memory space, but then unreachable, because there is no GC in C + +, these memory will never be back. In Java, these unreachable objects are collected by the GC, so programmers do not need to consider this part of the memory leak.

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

Therefore, through the above analysis, we know that there are also memory leaks in Java, but the scope is smaller than C + +. Because Java is linguistically guaranteed, any object is accessible and all unreachable objects are managed by GC.

For programmers, the GC is basically transparent and invisible. Although we have only a few functions to access the GC, such as the function System.GC () that runs the GC, this function does not guarantee that the JVM's garbage collector will execute, as defined by the Java language Specification. Because different JVM implementations may use different algorithms to manage GC. Typically, the GC thread has a lower priority level. There are also a number of strategies for JVM calls to GC, some of which have reached a certain level of memory usage, with GC beginning to work, timed execution, smooth execution GC, and Chinese execution GC. But generally, we don't need to care about that. Unless GC execution affects application performance on certain occasions, such as for web-based real-time systems such as online games, where users do not want the GC to suddenly interrupt application execution for garbage collection, we need to adjust the GC's parameters so that the GC can release the memory in a gentle way, For example, by decomposing garbage collection into a series of small steps, the hotspot JVM provided by Sun supports this feature.