Preface
I saw a question on segmentfault: Java has a complete GC mechanism, so will there be a memory leak problem in Java, and can I give a case of memory leak. This question view gives the complete answer to this question.
Introduction to garbage recycling mechanism
During the program running, each object is created, a certain amount of memory is allocated to store object data. If you just keep allocating memory, then the program will face the problem of insufficient memory sooner or later. So in any language, there will be a memory recovery mechanism to free up the memory of expired objects to ensure that the memory can be reused.
The memory recycling mechanism can be divided into two types according to the implementation roles. One is that programmers manually realize the release of memory (such as C language) and the other is the built-in memory recycling mechanism of the language, such as the java garbage collection mechanism to be introduced in this article.
Java's garbage collection mechanism
In the runtime environment of the program, the java virtual machine provides a system-level garbage collection (GC, Carbage Collection) thread, which is responsible for reclaiming memory occupied by objects that have lost references. The prerequisite for understanding GC is to understand some concepts related to garbage collection. These concepts are introduced one by one in the following.
The state of the object in the jvm heap area
Instances of Java objects are stored in the heap area of jvm. For GC threads, these objects have three states.
1. Touchable state: There are variable references in the program, so this object is touchable state.
2. Reactivated state: When no variables in the program refer to this object, the object will change from a touchable state to a reactivated state. The CG thread will prepare to call the finalize method of this object at a certain time (the finalize method inherits or rewrites the child object). The code in the finalize method may convert the object into a touchable state, otherwise the object will be converted into an untouchable state.
3. Untouchable state: The GC thread can recycle the memory of this object only when the object is in an untouchable state.
In order to correctly release objects, GC must monitor the running status of each object, including the application, citation, citation, assignment, etc. GC needs to monitor it, so GC will know no matter whether an object is in any state above.
As mentioned above, GC threads will execute the finalize method of resurrectable state objects at a certain time. So when will it be executed? Since different JVM implementers may use different algorithms to manage GC, at any time, developers cannot predict the timing of GC threads performing various operations (including detecting object state, releasing object memory, and calling object finalize methods). Although the GC thread can be reminded to perform garbage collection operations as soon as possible through the System.gc() and Runtime.gc() functions, this cannot guarantee that the GC thread will perform corresponding recycling operations immediately.
Memory leak
Memory leaks are caused by wrong designs that the program fails to release memory that is no longer used, resulting in waste of resources. GC will automatically clean up memory occupied by objects that have lost references. However, if some objects are always referenced due to programming errors, a memory leak will occur.
For example, the following example. An array is used to implement a stack, with two operations: stack entry and stack exit.
import com.sun.javafx.collections.ElementObservableListDecorator;import com.sun.swing.internal.plaf.metal.resources.metal_sv;import java.beans.ExceptionListener;import java.util.EmptyStackException;/** * Created by peng on 14-9-21. */public class MyStack { private Object[] elements; private int Increment = 10; private int size = 0; public MyStack(int size) { elements = new Object[size]; } //Put the stack public void push(Object o) { capacity(); elements[size++] = o; } //Put the stack public Object pop() { if (size == 0) throw new EmptyStackException(); return elements[--size]; } //Increase the capacity of the stack private void capacity() { if (elements.length != size) return; Object[] newArray = new Object[elements.length + Increment]; System.arraycopy(elements, 0, newArray, 0, size); } public static void main(String[] args) { MyStack stack = new MyStack(100); for (int i = 0; i < 100; i++) stack.push(new Integer(i)); for (int i = 0; i < 100; i++) { System.out.println(stack.pop().toString()); } }}This program is available and supports common stack entry and stack entry operations. However, there is a problem that has not been handled well, that is, when the stack operation is released, the reference to the stack element in the array is not released, which causes the program to keep a reference to this Object (this object is referenced by the array). GC always believes that this object is accessible, which means there is no need to talk about releasing its memory. This is a typical case of memory leaks. For this, the modified code is:
//Stack public Object pop() { if (size == 0) throw new EmptyStackException(); Object o = elements[--size]; elements[size] = null; return o; }The above article has a deep understanding of the Java garbage collection mechanism and memory leaks. This is all the content I have shared with you. I hope it can give you a reference and I hope you can support Wulin.com more.