Detailed explanation of memory leak code in Java language

An important feature of Java is that the garbage collector (GC) automatically manages the recycling of memory without requiring the programmer to free memory. Theoretically, the memory occupied by all objects that will no longer be used in Java can be recycled by GC, but Java also has memory leakage, but its performance is different from C + +.

Memory management in Java

To understand the memory leak in Java, you must first know how the memory in Java is managed.

In Java programs, we usually use new to allocate memory for objects, and these memory spaces are on the heap.

Here is an example:

Java uses directed graph for memory management:

In a directed graph, we call obj1 reachable, obj2 unreachable, and obviously unreachable can be cleaned up.

Memory release, that is, cleaning up unreachable objects, is determined and executed by GC, so GC will monitor the status of each object, including application, reference, referenced and assignment. The fundamental principle of releasing objects is that objects will no longer be used:

The object is given a null value null and has not been called since.

The other is to assign new values to objects, which reallocates memory space.

Generally, it is considered that allocating objects on the heap is expensive, but GC optimizes this operation: in C + +, when allocating a piece of memory on the heap, it will find a suitable memory to allocate. If the object is destroyed, this memory can be reused; In Java, it is like a long belt. Every time a new object is allocated, the Java "heap pointer" moves backward to the unallocated area. Therefore, the efficiency of Java in allocating memory is comparable to that of C + +.

But there is a problem with this way of working: if memory is applied frequently, resources will be exhausted. GC then intervenes, reclaiming space and making the objects in the heap more compact. In this way, there will always be enough memory space to allocate.

Reference count method during GC Cleanup: when a reference is connected to a new object, reference count + 1; When a reference leaves the scope or is set to null, the reference count is - 1. When GC finds that the count is 0, it reclaims the memory occupied by it. This overhead occurs throughout the life cycle of the referencing program and cannot handle circular references. Therefore, this method is only used to explain the working mode of GC, and will not be applied by any Java virtual machine.

Most GCS adopt an adaptive cleaning method (plus other additional technologies to improve speed), which is mainly based on finding any "live" objects, and then adopt an "adaptive, generational, stop copy, mark clean" garbage collector. It will not be introduced in detail, which is not the focus of this article.

Memory leak in Java

Memory leakage in Java, in a broad and popular sense, is that the memory of objects that will no longer be used can not be recycled, that is, memory leakage.

Memory leakage in Java is different from that in C + +.

In C + +, all objects allocated memory must be released manually by the programmer after they are no longer used. Therefore, each class will contain a destructor to complete the cleaning. If we forget to release some objects, it will cause memory leakage.

However, in Java, we don't have to (and can't) release memory by ourselves. Useless objects are automatically cleaned up by GC, which greatly simplifies our programming work. However, in fact, sometimes some objects that will no longer be used can't be released in the view of GC, which will cause memory leakage.

We know that objects have a life cycle, some long and some short. If objects with a long life cycle hold references with a short life cycle, memory leakage is likely to occur. Let's give a simple example:

In fact, we expect the object instance here to only work in the method1 () method, and it will not be used elsewhere. However, after the method1 () method is executed, the memory allocated by the object object object will not be considered as an object that can be released immediately. It will be released only after the object created by the simple class is released. Strictly speaking, this is a memory leak. The solution is to use object as a local variable in the method1 () method. Of course, if you have to write this, you can change it to this:

In this way, the memory previously allocated by "newobject()" can be recycled by GC.

Here, the memory leak of Java should be clear. It is further explained below:

When the allocated memory in the heap is not released, all ways that can access this memory are deleted (such as pointer re assignment). This is for languages such as C + +. GC in Java will help us deal with this situation, so we don't need to care.

When the memory object is clearly no longer needed, it still retains this memory and its access method (Reference), which is a possible memory leak in all languages. If we are not careful during programming, it is easy to happen. If it is not too serious, it may be just a short memory leak.

Some examples and solutions prone to memory leakage

The situation in the above example is easy to happen, and it is also the case that we are most likely to ignore and cause memory leakage. The solution principle is to minimize the scope of the object (for example, in Android studio, the above code will issue a warning and give suggestions to rewrite the member variables of the class into local variables in the method) and manually set null values.

As for the scope, we need to pay more attention when we write code; For the manual setting of null value, we can take a look at the internal method of deleting the specified node in the Java container LinkedList source code (see: Java LinkedList source code interpretation (JDK1.8)):

We know that the Java container ArrayList is implemented by arrays (refer to: Java ArrayList source code interpretation (JDK1.8)). If we want to write a pop() (Pop-Up) method for it, it may be as follows: