Je me demandais ce qui se passe lorsque vous essayez d'attraper une StackOverflowError et que vous avez proposé la méthode suivante:
class RandomNumberGenerator {
static int cnt = 0;
public static void main(String[] args) {
try {
main(args);
} catch (StackOverflowError ignore) {
System.out.println(cnt++);
}
}
}
Maintenant ma question:
Pourquoi cette méthode imprime-t-elle «4»?
Je pensais que c'était peut-être parce qu'il System.out.println()
fallait 3 segments sur la pile d'appels, mais je ne sais pas d'où vient le numéro 3. Lorsque vous regardez le code source (et le bytecode) de System.out.println()
, cela conduirait normalement à beaucoup plus d'appels de méthode que 3 (donc 3 segments sur la pile d'appels ne seraient pas suffisants). Si c'est à cause des optimisations que la VM Hotspot applique (méthode inlining), je me demande si le résultat serait différent sur une autre VM.
Modifier :
Comme la sortie semble être très spécifique à la JVM, j'obtiens le résultat 4 en utilisant
Java (TM) SE Runtime Environment (build 1.6.0_41-b02)
Java HotSpot (TM) 64-Bit Server VM (build 20.14-b01, mode mixte)
Explication pourquoi je pense que cette question est différente de Comprendre la pile Java :
Ma question n'est pas de savoir pourquoi il y a un cnt> 0 (évidemment parce qu'il System.out.println()
nécessite une taille de pile et en jette une autre StackOverflowError
avant que quelque chose ne soit imprimé), mais pourquoi il a la valeur particulière de 4, respectivement 0,3,8,55 ou autre chose systèmes.
5
, 6
et 38
avec Java 1.7.0_10