Java memory leaks

Original address:

What is a memory leak

When some objects are no longer used by the application, the garbage collector cannot release them because they are still referenced.

Is the case of memory leaks.

The middle part of the diagram is where memory leaks occur.

Why is memory leaking

Let's take a look at the example and see why there is a memory leak. The reference to object a when B. A's life cycle is t1-t4 while the life cycle of B is t2-t3. So when B is not in use in the program, a still has a reference to B, at which point B cannot be recycled by GC. This can cause a memory leak, because a may have done the same thing to other objects, and B might have a reference to multiple objects, so that memory is definitely not enough.

How Java is managing memory

From the above we have roughly understood what a memory leak generally is, but how does Java manage memory?

The memory management of Java is the allocation and release of objects. In Java, programmers need to request memory space for each object through the keyword new (except for the base type), and all objects allocate space in the heap. In addition, the release of the object is determined and executed by the GC. In Java, the allocation of memory is done by the program, and the release of memory is a GC, the two lines of the method does simplify the work of the programmer. But it also adds to the JVM's work. This is one of the reasons why the Java program is running slower. Because, in order for the GC to properly dispose of objects, the GC must monitor the running state of each object, including the application, reference, reference, assignment, etc. of the object, which the GC needs to monitor.

The object's state is monitored to release the object more accurately and in a timely manner, and the fundamental principle of releasing the object is that the object is no longer referenced.

To better understand how the GC works, we can consider the object as a vertex of the directed graph, consider the reference relationship as a directed edge of the graph, and have a directed edge from the referrer to the cited object. In addition, each thread object can be used as the starting vertex of a graph, for example, when most programs are executed from the main process, the graph is a root tree that starts with the main process vertex. In this graph, the object that the root vertex can reach is a valid object, and the GC will not reclaim those objects. if an object (connected sub-graph) and this root vertex are unreachable (note that the graph is a forward graph), then we think that this (these) objects are no longer referenced and can be recycled by GC.

Below, let's give an example of how memory management is represented by a graph. For every moment of the program, we have a graph of graphs that represent the memory allocations of the JVM. On the right, the left program runs to line 6th.

Java uses a graph-like approach to memory management, which eliminates the problem of reference loops, such as having three objects and referencing each other, so that GC can reclaim them as long as they are unreachable from the root process. The advantage of this approach is that the precision of managing memory is high, but the efficiency is low. Another common memory management technique is the use of counters, such as the COM model, which uses counter-mode management artifacts, which are low-precision rows (difficult to handle circular references) compared to a forward graph, but perform efficiently.

Deep memory leaks

Below, we can describe what a memory leak is. In Java, the memory leak is the existence of some assigned objects, these objects have the following two characteristics, first of all, these objects are accessible, that is, in the graph, the existence of the path can be connected to it, and secondly, these objects are useless, that is, the program will no longer use these objects. If the object satisfies both conditions, these objects can be judged as a memory leak in Java, which is not reclaimed by the GC, but it consumes memory.

In C + +, memory leaks are larger in scope. Some objects are allocated memory space, and then unreachable, because there is no GC in C + +, the memory will never be returned. 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 the edge (do not need to manage the release of vertices). In this way, Java improves the efficiency of programming.

Let's look at a section of effective Java that optimizes the code for the stack operation

 Public Object Pop() {    if (size == 0)    Throw New emptystackexception();    Object result = Elements[--size];    Elements[size] = NULL; //Eliminate obsolete reference    return result;}

Elements[size] = NULL in the code, which is to delete the reference that points to the stack element. Thus there is no reference to the data that is not needed (note that if there is no line, only the value of size is reduced by one).

How to prevent memory leaks

The following is some quick hands-on tips for preventing memory leaks.

1. Pay attention to Collection classes, such as HASHMAP, ArrayList, etc., as they ar E Common places to find memory leaks. When they was declared static, their life time was the same as the life time of the application.

2. Pay attention to event listeners and callbacks. A memory leak may occur if a listener was registered but not unregistered when the class was not being used any longer.

3. "If a class manages its own memory, the Programer should is alert for memory leaks." [1] Often times member variables of an object, the point to the other objects need to is null out.

Why substring () method in JDK 6 can cause memory leaks?

See: The substring () Method in JDK 6 and JDK 7

In summary, Java also has a memory leak problem, the main reason is that some objects are not used, but they are still referenced.

2014-11-10 18:59:04

Brave,happy,thanksgiving!

Java memory leaks