In-depth understanding of Java garbage collection mechanism and memory leaks

Preface

I saw a question on segmentfault: Java has a complete GC mechanism, so will there be memory leaks in Java, and can you give a case of memory leaks. This question view gives the complete answer to this question.

Introduction to the garbage collection mechanism

During the running of the program, every time an object is created, a certain amount of memory will be allocated to store object data. If you just keep allocating memory, the program will sooner or later face the problem of insufficient memory. Therefore, in any language, there will be a memory recycling mechanism to release 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 different implementation roles. One is that the programmer manually releases the memory (such as C language) and the other is the language's built-in memory recycling mechanism. For example, this article will Introducing the java garbage collection mechanism.

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 recycling lost references. The memory occupied by the object. The prerequisite for understanding GC is to understand some concepts related to garbage collection. These concepts are introduced one by one below.

The state of objects in the jvm heap area

Instances of Java objects are stored in the jvm heap area. For GC threads, these objects have three states.

1. Reachable state: If there are variable references in the program, then this object is in a reachable state.

2. Resurrectable state: When no variable in the program refers to this object, then the object changes from the touchable state to the resurrectable 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 sub-Object). The code in the finalize method may convert the object to a touchable state, otherwise the object will be converted to an untouchable state.

3. Unreachable state: Only when the object is in an unreachable state, the GC thread can reclaim the memory of this object.

In order to release objects correctly, GC must monitor the running status of each object, including object application, reference, being referenced, assignment, etc. GC needs to monitor. So no matter whether an object is in any of the above states, the GC will know it.

As mentioned above, the GC thread will execute the finalize method of the resurrectable state object at a certain time, so when will it be executed? Since different JVM implementers may use different algorithms to manage GC, developers cannot predict the timing of various operations (including detecting object status, releasing object memory, and calling the object's finalize method) by the GC thread at any time. Although the GC thread can be reminded to perform garbage collection operations as soon as possible through the System.gc() and Runtime.gc() functions, there is no guarantee that the GC thread will perform the corresponding recycling operations immediately.

Memory leak

Memory leak refers to the failure of the program to release memory that is no longer used due to incorrect design, resulting in a waste of resources. GC will automatically clean up the memory occupied by objects that have lost references. However, if some objects are always referenced due to a programming error, a memory leak will occur.

For example, the following example. A stack is implemented using an array, with two operations: push and pop.

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];
  }
 
  //入栈
  public void push(Object o) {
    capacity();
    elements[size++] = o;
  }
 
  //出栈
  public Object pop() {
    if (size == 0)
      throw new EmptyStackException();
    return elements[--size];
  }
 
  //增加栈的容量
  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 push and pop operations. However, there is a problem that has not been handled well, that is, when popping the stack, the reference to the popped element in the array is not released. This causes the program to keep a reference to this Object (this object is referenced by the array). The GC will always think that This object is reachable, let alone releasing its memory. This is a typical case of memory leak. In response to this, the modified code is:

//出栈
  public Object pop() {
    if (size == 0)
      throw new EmptyStackException();
    Object o = elements[--size];
    elements[size] = null;
    return o;
  }

The above article on in-depth understanding of Java garbage collection mechanism and memory leaks is all the content shared by the editor. I hope it can give you a reference, and I hope you will learn more Support PHP Chinese website.

For more in-depth understanding of Java garbage collection mechanism and memory leak related articles, please pay attention to the PHP Chinese website!