Que se passe-t-il lorsque la mémoire est insuffisante pour lancer une erreur OutOfMemoryError?

Je suis conscient que chaque objet nécessite une mémoire de tas et que chaque primitive / référence sur la pile nécessite une mémoire de pile.

Lorsque j'essaie de créer un objet sur le tas et que la mémoire est insuffisante pour cela, la JVM crée une java.lang.OutOfMemoryError sur le tas et me la lance.

Donc implicitement, cela signifie qu'il y a de la mémoire réservée par la JVM au démarrage.

Que se passe-t-il lorsque cette mémoire réservée est utilisée (elle serait certainement utilisée, lisez la discussion ci-dessous) et que la JVM n'a pas assez de mémoire sur le tas pour créer une instance de java.lang.OutOfMemoryError ?

Est-ce que ça se bloque? Ou me lancerait-il nullcar il n'y a pas de mémoire dans newune instance de MOO?

try {
    Object o = new Object();
    // and operations which require memory (well.. that's like everything)
} catch (java.lang.OutOfMemoryError e) {
    // JVM had insufficient memory to create an instance of java.lang.OutOfMemoryError to throw to us
    // what next? hangs here, stuck forever?
    // or would the machine decide to throw us a "null" ? (since it doesn't have memory to throw us anything more useful than a null)
    e.printStackTrace(); // e.printStackTrace() requires memory too.. =X
}

==

Pourquoi la JVM ne pouvait-elle pas réserver suffisamment de mémoire?

Quelle que soit la quantité de mémoire réservée, il est toujours possible d'utiliser cette mémoire si la JVM n'a pas de moyen de "récupérer" cette mémoire:

try {
    Object o = new Object();
} catch (java.lang.OutOfMemoryError e) {
    // JVM had 100 units of "spare memory". 1 is used to create this OOM.
    try {
        e.printStackTrace();
    } catch (java.lang.OutOfMemoryError e2) {
        // JVM had 99 units of "spare memory". 1 is used to create this OOM.
        try {
            e.printStackTrace();
        } catch (java.lang.OutOfMemoryError e3) {
            // JVM had 98 units of "spare memory". 1 is used to create this OOM.
            try {
                e.printStackTrace();
            } catch (java.lang.OutOfMemoryError e4) {
                // JVM had 97 units of "spare memory". 1 is used to create this OOM.
                try {
                    e.printStackTrace();
                } catch (java.lang.OutOfMemoryError e5) {
                    // JVM had 96 units of "spare memory". 1 is used to create this OOM.
                    try {
                        e.printStackTrace();
                    } catch (java.lang.OutOfMemoryError e6) {
                        // JVM had 95 units of "spare memory". 1 is used to create this OOM.
                        e.printStackTrace();
                        //........the JVM can't have infinite reserved memory, he's going to run out in the end
                    }
                }
            }
        }
    }
}

Ou plus précisément:

private void OnOOM(java.lang.OutOfMemoryError e) {
    try {
        e.printStackTrace();
    } catch (java.lang.OutOfMemoryError e2) {
        OnOOM(e2);
    }
}

La JVM ne manque jamais vraiment de mémoire. Il effectue à l'avance le calcul de la mémoire de la pile de segments de mémoire.

La structure de la JVM, chapitre 3 , section 3.5.2 indique:

• Si les piles de machines virtuelles Java peuvent être étendues dynamiquement et que l'expansion est tentée mais que la mémoire insuffisante peut être mise à disposition pour effectuer l'expansion, ou si la mémoire insuffisante peut être mise à disposition pour créer la pile de machines virtuelles Java initiale pour un nouveau thread, Java virtual la machine lance un OutOfMemoryError .

Pour Heap , Section 3.5.3.

• Si un calcul nécessite plus de tas que ce qui peut être mis à disposition par le système de gestion automatique du stockage, la machine virtuelle Java lance un OutOfMemoryError.

Donc, il fait un calcul à l'avance avant de faire l'allocation de l'objet.

Ce qui se passe, c'est que la JVM essaie d'allouer de la mémoire à un objet de la mémoire appelé région de génération permanente (ou PermSpace). Si l'allocation échoue (même après que la JVM a invoqué le garbage collector pour essayer d'allouer de l'espace libre), elle lance un OutOfMemoryError. Même les exceptions nécessitent un espace mémoire afin que l'erreur soit renvoyée indéfiniment.

Lectures complémentaires. ? De plus, cela OutOfMemoryErrorpeut se produire dans différentes structures JVM.

Graham Borland semble avoir raison : au moins ma JVM réutilise apparemment OutOfMemoryErrors. Pour tester cela, j'ai écrit un programme de test simple:

class OOMTest {
    private static void test (OutOfMemoryError o) {
        try {
            for (int n = 1; true; n += n) {
                int[] foo = new int[n];
            }
        } catch (OutOfMemoryError e) {
            if (e == o)
                System.out.println("Got the same OutOfMemoryError twice: " + e);
            else test(e);
        }
    }
    public static void main (String[] args) {
        test(null);
    }
}

L'exécuter produit cette sortie:

$ javac OOMTest.java && java -Xmx10m OOMTest 
Got the same OutOfMemoryError twice: java.lang.OutOfMemoryError: Java heap space

BTW, la JVM que j'exécute (sur Ubuntu 10.04) est la suivante:

$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Edit: J'ai essayé de voir ce qui se passerait si je forçais la JVM à manquer complètement de mémoire en utilisant le programme suivant:

class OOMTest2 {
    private static void test (int n) {
        int[] foo;
        try {
            foo = new int[n];
            test(n * 2);
        }
        catch (OutOfMemoryError e) {
            test((n+1) / 2);
        }
    }
    public static void main (String[] args) {
        test(1);
    }
}

En fin de compte, il semble boucler pour toujours. Cependant, curieusement, essayer de terminer le programme avec Ctrl+ Cne fonctionne pas, mais ne donne que le message suivant:

Java HotSpot(TM) 64-Bit Server VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated

La plupart des environnements d'exécution pré-alloueront au démarrage, ou réserveront autrement, suffisamment de mémoire pour faire face aux situations de famine de mémoire. J'imagine que la plupart des implémentations JVM sensées feraient cela.

La dernière fois que je travaillais en Java et que j'utilisais un débogueur, l'inspecteur de tas a montré que la JVM avait alloué une instance de OutOfMemoryError au démarrage. En d'autres termes, il alloue l'objet avant que votre programme ne commence à consommer, et encore moins à manquer de mémoire.

Dans la spécification JVM, chapitre 3.5.2:

Si les piles de machines virtuelles Java peuvent être développées dynamiquement et que l'expansion est tentée mais que la mémoire insuffisante peut être mise à disposition pour effectuer l'expansion, ou si la mémoire insuffisante peut être mise à disposition pour créer la pile de machines virtuelles Java initiale pour un nouveau thread, Java virtual la machine lance unOutOfMemoryError .

Chaque machine virtuelle Java doit garantir qu'elle lancera un fichier OutOfMemoryError. Cela implique qu'il doit être capable de créer une instance deOutOfMemoryError (ou de l'avoir créé à l'avance) même s'il n'y a plus d'espace de stockage.

Bien qu'il ne doive pas garantir, qu'il reste suffisamment de mémoire pour l'attraper et imprimer une belle trace de pile ...

Une addition

Vous avez ajouté du code pour montrer que la JVM risque de manquer d'espace de tas si elle devait en lancer plusieurs OutOfMemoryError . Mais une telle mise en œuvre violerait l'exigence d'en haut.

Il n'est pas nécessaire que les instances levées OutOfMemoryErrorsoient uniques ou créées à la demande. Une machine virtuelle Java peut préparer exactement une instance de OutOfMemoryErrorlors du démarrage et la lancer chaque fois qu'elle manque d'espace de stockage - ce qui est une fois, dans un environnement normal. En d'autres termes: l'instance OutOfMemoryErrorque nous voyons pourrait être un singleton.

Question interessante :-). Alors que les autres ont donné de bonnes explications sur les aspects théoriques, j'ai décidé de l'essayer. C'est sur Oracle JDK 1.6.0_26, Windows 7 64 bits.

Configuration de test

J'ai écrit un programme simple pour épuiser la mémoire (voir ci-dessous).

Le programme ne fait que créer un statique java.util.Listet continue à y bourrer de nouvelles chaînes jusqu'à ce que le MOO soit lancé. Il le rattrape ensuite et continue le bourrage dans une boucle sans fin (pauvre JVM ...).

Résultat du test

Comme on peut le voir sur la sortie, les quatre premières fois que OOME est lancé, il est livré avec une trace de pile. Après cela, les OOME suivants ne s'impriment que java.lang.OutOfMemoryError: Java heap spacesi printStackTrace()est invoqué.

Donc, apparemment, la JVM fait un effort pour imprimer une trace de pile si elle le peut, mais si la mémoire est vraiment serrée, elle omet simplement la trace, comme le suggèrent les autres réponses.

Le code de hachage de OOME est également intéressant. Notez que les premiers OOME ont tous des hachages différents. Une fois que la JVM commence à omettre les traces de pile, le hachage est toujours le même. Cela suggère que la JVM utilisera des instances OOME fraîches (préallouées?) Aussi longtemps que possible, mais si la poussée vient à bout, elle réutilisera simplement la même instance plutôt que de n'avoir rien à jeter.

Production

Remarque: J'ai tronqué certaines traces de pile pour rendre la sortie plus facile à lire ("[...]").

iteration 0
iteration 100000
iteration 200000
iteration 300000
iteration 400000
iteration 500000
iteration 600000
iteration 700000
iteration 800000
iteration 900000
iteration 1000000
iteration 1100000
iteration 1200000
iteration 1300000
iteration 1400000
iteration 1500000
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 1069480624
Keep on trying...
java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Unknown Source)
    at java.util.Arrays.copyOf(Unknown Source)
    at java.util.ArrayList.ensureCapacity(Unknown Source)
    at java.util.ArrayList.add(Unknown Source)
    at testsl.Div.gobbleUpMemory(Div.java:23)
    at testsl.Div.exhaustMemory(Div.java:12)
    at testsl.Div.main(Div.java:7)
java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Unknown Source)
[...]
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 616699029
Keep on trying...
java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Unknown Source)
[...]
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 2136955031
Keep on trying...
java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Unknown Source)
[...]
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 1535562945
Keep on trying...
java.lang.OutOfMemoryError: Java heap space
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 1734048134
Keep on trying...
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 1734048134
Keep on trying...
java.lang.OutOfMemoryError: Java heap space
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 1734048134
Keep on trying...
[...]

Le programme

public class Div{
    static java.util.List<String> list = new java.util.ArrayList<String>();

    public static void main(String[] args) {
        exhaustMemory();
    }

    private static void exhaustMemory() {
        try {
            gobbleUpMemory();
        } catch (OutOfMemoryError e) {
            System.out.println("Ouch: " + e+"; hash: "+e.hashCode());
            e.printStackTrace();
            System.out.println("Keep on trying...");
            exhaustMemory();
        }
    }

    private static void gobbleUpMemory() {
        for (int i = 0; i < 10000000; i++) {
            list.add(new String("some random long string; use constructor to force new instance"));
            if (i % 10000000== 0) {
                System.out.println("iteration "+i);
            }
        }

    }
}

Je suis à peu près sûr, la JVM s'assurera absolument qu'elle a au moins assez de mémoire pour lever une exception avant de manquer de mémoire.

Les exceptions indiquant une tentative de violation des limites d'un environnement de mémoire gérée sont gérées par le runtime dudit environnement, dans ce cas la JVM. La JVM est son propre processus, qui exécute l'IL de votre application. Si un programme tente d'effectuer un appel qui étend la pile d'appels au-delà des limites ou d'allouer plus de mémoire que la JVM ne peut en réserver, le runtime lui-même injectera une exception, ce qui entraînera le déroulement de la pile d'appels. Quelle que soit la quantité de mémoire dont votre programme a besoin actuellement, ou la profondeur de sa pile d'appels, la JVM aura alloué suffisamment de mémoire dans ses propres limites de processus pour créer ladite exception et l'injecter dans votre code.

Vous semblez confondre la mémoire virtuelle réservée par la JVM dans laquelle la JVM exécute des programmes Java avec la mémoire native du système d'exploitation hôte dans laquelle la JVM est exécutée en tant que processus natif. La JVM de votre machine s'exécute dans la mémoire gérée par le système d'exploitation, et non dans la mémoire que la JVM a réservée pour exécuter des programmes Java.

Lectures complémentaires:

• http://java.sys-con.com/node/1229281
• http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=%2Fcom.ibm.java.doc.igaa%2F_1vg000121410cbe-1195c23a635-7ffa_1001.html

Et pour finir , essayer d' attraper une java.lang.Error (et ses classes descendantes) afin d'imprimer une trace de pile peut ne pas vous donner d'informations utiles. Vous voulez un vidage de tas à la place.

Pour clarifier davantage la réponse de @Graham Borland, fonctionnellement, la JVM le fait au démarrage:

private static final OutOfMemoryError OOME = new OutOfMemoryError();

Plus tard, la JVM exécute l'un des bytecodes Java suivants: «nouveau», «anewarray» ou «multianewarray». Cette instruction oblige la JVM à exécuter un certain nombre d'étapes dans un état de mémoire insuffisante:

1. Appelez une fonction native, par exemple allocate(). allocate()tente d'allouer de la mémoire pour certains une nouvelle instance d'une classe ou d'un tableau particulier.
2. Cette demande d'allocation échoue, de sorte que la JVM appelle une autre fonction native, par exemple doGC(), qui tente de faire le garbage collection.
3. Lorsque cette fonction revient, allocate()essaie à nouveau d'allouer de la mémoire à l'instance.
4. Si cela échoue (*), la machine throw OOME;virtuelle Java, dans allocate (), fait simplement un , se référant à l'OOME qu'elle a instanciée au démarrage. Notez qu'il n'a pas eu à allouer cet OOME, il y fait simplement référence.

Évidemment, ce ne sont pas des étapes littérales; ils varieront de JVM à JVM dans l'implémentation, mais c'est l'idée de haut niveau.

(*) Une quantité importante de travail se produit ici avant d'échouer. La JVM tentera d'effacer les objets SoftReference, tentera l'allocation directement dans la génération sécurisée lors de l'utilisation d'un collecteur générationnel, et éventuellement d'autres choses, comme la finalisation.

Les réponses qui disent que la JVM pré-allouera OutOfMemoryErrorssont en effet correctes.
En plus de tester cela en provoquant une situation de mémoire insuffisante, nous pouvons simplement vérifier le tas de n'importe quelle machine virtuelle Java (j'ai utilisé un petit programme qui fait juste une mise en veille, en l'exécutant à l'aide de la machine virtuelle Java Hotspot de Java 8 mise à jour 31).

En utilisant jmap nous voyons qu'il semble y avoir 9 instances de OutOfMemoryError (même si nous avons beaucoup de mémoire):

> jmap -histo 12103 | grep OutOfMemoryError
 71: 9 288 java.lang.OutOfMemoryError
170: 1 32 [Ljava.lang.OutOfMemoryError;

On peut alors générer un vidage de tas:

> jmap -dump: format = b, file = heap.hprof 12315

et ouvrez-le à l'aide d' Eclipse Memory Analyzer , où une requête OQL montre que la JVM semble réellement pré-allouer OutOfMemoryErrorspour tous les messages possibles:

Le code de la machine virtuelle Java 8 Hotspot qui les préalloue en fait peut être trouvé ici , et ressemble à ceci (avec certaines parties omises):

...
// Setup preallocated OutOfMemoryError errors
k = SystemDictionary::resolve_or_fail(vmSymbols::java_lang_OutOfMemoryError(), true, CHECK_false);
k_h = instanceKlassHandle(THREAD, k);
Universe::_out_of_memory_error_java_heap = k_h->allocate_instance(CHECK_false);
Universe::_out_of_memory_error_metaspace = k_h->allocate_instance(CHECK_false);
Universe::_out_of_memory_error_class_metaspace = k_h->allocate_instance(CHECK_false);
Universe::_out_of_memory_error_array_size = k_h->allocate_instance(CHECK_false);
Universe::_out_of_memory_error_gc_overhead_limit =
  k_h->allocate_instance(CHECK_false);

...

if (!DumpSharedSpaces) {
  // These are the only Java fields that are currently set during shared space dumping.
  // We prefer to not handle this generally, so we always reinitialize these detail messages.
  Handle msg = java_lang_String::create_from_str("Java heap space", CHECK_false);
  java_lang_Throwable::set_message(Universe::_out_of_memory_error_java_heap, msg());

  msg = java_lang_String::create_from_str("Metaspace", CHECK_false);
  java_lang_Throwable::set_message(Universe::_out_of_memory_error_metaspace, msg());
  msg = java_lang_String::create_from_str("Compressed class space", CHECK_false);
  java_lang_Throwable::set_message(Universe::_out_of_memory_error_class_metaspace, msg());

  msg = java_lang_String::create_from_str("Requested array size exceeds VM limit", CHECK_false);
  java_lang_Throwable::set_message(Universe::_out_of_memory_error_array_size, msg());

  msg = java_lang_String::create_from_str("GC overhead limit exceeded", CHECK_false);
  java_lang_Throwable::set_message(Universe::_out_of_memory_error_gc_overhead_limit, msg());

  msg = java_lang_String::create_from_str("/ by zero", CHECK_false);
  java_lang_Throwable::set_message(Universe::_arithmetic_exception_instance, msg());

  // Setup the array of errors that have preallocated backtrace
  k = Universe::_out_of_memory_error_java_heap->klass();
  assert(k->name() == vmSymbols::java_lang_OutOfMemoryError(), "should be out of memory error");
  k_h = instanceKlassHandle(THREAD, k);

  int len = (StackTraceInThrowable) ? (int)PreallocatedOutOfMemoryErrorCount : 0;
  Universe::_preallocated_out_of_memory_error_array = oopFactory::new_objArray(k_h(), len, CHECK_false);
  for (int i=0; i<len; i++) {
    oop err = k_h->allocate_instance(CHECK_false);
    Handle err_h = Handle(THREAD, err);
    java_lang_Throwable::allocate_backtrace(err_h, CHECK_false);
    Universe::preallocated_out_of_memory_errors()->obj_at_put(i, err_h());
  }
  Universe::_preallocated_out_of_memory_error_avail_count = (jint)len;
}
...

et ce code montre que la JVM essaiera d'abord d'utiliser l'une des erreurs pré-allouées avec de l'espace pour une trace de pile, puis retombera sur une sans trace de pile:

oop Universe::gen_out_of_memory_error(oop default_err) {
  // generate an out of memory error:
  // - if there is a preallocated error with backtrace available then return it wth
  //   a filled in stack trace.
  // - if there are no preallocated errors with backtrace available then return
  //   an error without backtrace.
  int next;
  if (_preallocated_out_of_memory_error_avail_count > 0) {
    next = (int)Atomic::add(-1, &_preallocated_out_of_memory_error_avail_count);
    assert(next < (int)PreallocatedOutOfMemoryErrorCount, "avail count is corrupt");
  } else {
    next = -1;
  }
  if (next < 0) {
    // all preallocated errors have been used.
    // return default
    return default_err;
  } else {
    // get the error object at the slot and set set it to NULL so that the
    // array isn't keeping it alive anymore.
    oop exc = preallocated_out_of_memory_errors()->obj_at(next);
    assert(exc != NULL, "slot has been used already");
    preallocated_out_of_memory_errors()->obj_at_put(next, NULL);

    // use the message from the default error
    oop msg = java_lang_Throwable::message(default_err);
    assert(msg != NULL, "no message");
    java_lang_Throwable::set_message(exc, msg);

    // populate the stack trace and return it.
    java_lang_Throwable::fill_in_stack_trace_of_preallocated_backtrace(exc);
    return exc;
  }
}