Compréhension approfondie du mécanisme de récupération de place Java et des fuites de mémoire

Avant-propos

J'ai vu une question sur segmentfault : Java a un mécanisme GC complet, y aura-t-il donc des fuites de mémoire en Java, et pouvez-vous donner un cas de fuite de mémoire. Cette vue question donne la réponse complète à cette question.

Introduction au mécanisme de récupération de place

Pendant l'exécution du programme, chaque fois qu'un objet est créé, une certaine quantité de mémoire sera allouée pour stocker les données de l'objet. Si vous continuez simplement à allouer de la mémoire, le programme sera tôt ou tard confronté au problème d'une mémoire insuffisante. Par conséquent, dans n'importe quelle langue, il y aura un mécanisme de recyclage de mémoire pour libérer la mémoire des objets expirés afin de garantir que la mémoire puisse être réutilisée.

Le mécanisme de recyclage de la mémoire peut être divisé en deux types selon les différents rôles de mise en œuvre. L'un est que le programmeur libère manuellement la mémoire (comme le langage C) et l'autre est le mécanisme de recyclage de mémoire intégré de. le langage.Par exemple, cet article présentera le mécanisme de récupération de place Java.

Mécanisme de récupération de place de Java

Dans l'environnement d'exécution du programme, la machine virtuelle Java fournit un thread de récupération de place au niveau du système (GC, Carbage Collection), qui est responsable du recyclage des références perdues . La mémoire occupée par l'objet. La condition préalable à la compréhension de GC est de comprendre certains concepts liés au garbage collection. Ces concepts sont présentés un par un ci-dessous.

L'état des objets dans la zone de tas jvm

Les instances d'objets Java sont stockées dans la zone de tas jvm. Pour les threads GC, ces objets ont trois états.

1. État accessible : s'il y a des références de variables dans le programme, alors cet objet est dans un état accessible.

2. État résurrectable : Lorsqu'aucune variable du programme ne fait référence à cet objet, l'objet passe de l'état touchable à l'état ressuscitable. Le thread CG se préparera à appeler la méthode finalize de cet objet à un certain moment (la méthode finalize hérite ou remplace le sous-objet). Le code de la méthode finalize peut convertir l'objet en un état tactile, sinon l'objet sera). converti à un état intouchable.

3. État intouchable : Ce n'est que lorsque l'objet est dans un état intouchable que le thread GC peut récupérer la mémoire de cet objet.

Afin de libérer correctement les objets, GC doit surveiller l'état d'exécution de chaque objet, y compris l'application de l'objet, la référence, la référence, l'affectation, etc. GC doit tous surveiller. Ainsi, peu importe si un objet se trouve dans l'un des états ci-dessus, le GC le saura.

Comme mentionné ci-dessus, le thread GC exécutera la méthode finalize de l'objet d'état ressuscitable à un certain moment, alors quand sera-t-il exécuté ? Étant donné que différents implémenteurs de JVM peuvent utiliser différents algorithmes pour gérer GC, les développeurs ne peuvent pas prédire le timing de diverses opérations (y compris la détection de l'état de l'objet, la libération de la mémoire de l'objet et l'appel de la méthode finalize de l'objet) par le thread GC à tout moment. Bien qu'il soit possible de rappeler au thread GC d'effectuer les opérations de garbage collection dès que possible via les fonctions System.gc() et Runtime.gc(), rien ne garantit que le thread GC effectuera immédiatement les opérations de recyclage correspondantes.

Fuite de mémoire

La fuite de mémoire fait référence à l'échec du programme à libérer de la mémoire qui n'est plus utilisée en raison d'une conception incorrecte, entraînant un gaspillage de ressources. GC nettoiera automatiquement la mémoire occupée par les objets ayant perdu des références. Cependant, si certains objets sont toujours référencés à cause d'une erreur de programmation, une fuite mémoire se produira.

Par exemple, l'exemple suivant. Une pile est implémentée à l'aide d'un tableau, avec deux opérations : push et 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());
    }
  }
}

Ce programme est disponible et prend en charge les opérations push et pop courantes. Cependant, il existe un problème qui n'a pas été bien géré, c'est-à-dire que lors du popping de la pile, la référence à l'élément sauté dans le tableau n'est pas libérée. Cela amène le programme à conserver une référence à cet objet (cet objet est référencé). par le tableau). Le GC pensera toujours que cet objet est accessible, sans parler de libérer sa mémoire. Il s'agit d'un cas typique de fuite de mémoire. En réponse à cela, le code modifié est :

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

L'article ci-dessus sur la compréhension approfondie du mécanisme de récupération de place Java et des fuites de mémoire est tout le contenu partagé par l'éditeur, j'espère qu'il pourra vous le donner. une référence. J'espère également que veuillez prendre en charge le site Web chinois PHP.

Pour une compréhension plus approfondie du mécanisme de récupération de place Java et des articles liés aux fuites de mémoire, veuillez prêter attention au site Web PHP chinois !