Dans l'une de mes interviews antérieures, quelqu'un m'a demandé d'écrire un code pour planter la JVM. J'ai dit système.exit (). Est-ce correct? Y a-t-il de meilleures réponses?
Clarification: Je peux inclure mon morceau de code pendant le développement et le déploiement. Ce n'est pas que JVM est déjà en cours d'exécution et je dois écrire un code de piratage pour écraser l'autre JVM.
5 Réponses :
Je ne pense pas poliment demander que la JVM se termine vraiment comme "l'écrasement". Vous devriez demander à l'interview exactement ce qu'ils signifiaient par "crash". Par exemple:
(Il y a certainement été des problèmes de compilateur JIT au cours des dernières âges, j'ai eu un programme de Java pur qui serait systématiquement segfault, mais pourrait être «fixé» en faisant ce qui ressemblait à un changement de non-OP.)
simple: Soit souffler la pile avec une récursion infinie ou exécuter le jvm hors du tas d'objets.
plus compliqué serait d'exécuter le JVM hors du tas interne - vous pouvez probablement faire cela avec une sorte de boucle de chargement de classe , mais cela prendrait du travail. p>
sinon vous devez exploiter une sorte de bug, ou au moins tomber dans JNI. p>
public class Recur {
public static void main(String[] argv) {
recur();
}
static void recur() {
Object[] o = null;
try {
while(true) {
Object[] newO = new Object[1];
newO[0] = o;
o = newO;
}
}
finally {
recur();
}
}
}
C:\JavaTools>java Recur
#
# An unexpected error has been detected by Java Runtime Environment:
#
# EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x000000006dad5c3d, pid=6816, tid
=5432
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.2-b01 mixed mode windows-amd64)
# Problematic frame:
# V [jvm.dll+0x2e5c3d]
#
# An error report file with more information is saved as:
# C:\JavaTools\hs_err_pid6816.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Ceci est juste à court de mec de la pile ou de la mémoire tasse de java, ce n'est pas la même chose que de crash de la JVM. Consultez la réponse de Peter Lawrey à ce qu'on ressemble un crash JVM.
La définition de "crash" est quelque peu subjective. Le schéma dangereux est quelque chose que je n'avais pas pensé. Mais en cours d'exécution de la JVM du tas interne entraînerait probablement un crash "vrai".
(Notez que le JVM "généralement" gère la récursion infinie avec une fermeture d'exception non manquée, mais il est fortement dépendant du contexte.)
Vous pouvez utiliser la classe Imprime P> dangereux code> dangereux à utiliser comme vous pourriez deviner. #
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007ff1c2f23368, pid=2630, tid=140676351506176
#
# JRE version: 7.0-b147
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b17 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V [libjvm.so+0x82c368] Unsafe_GetNativeByte+0xa8
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /nfs/peter/IdeaProjects/scratch/hs_err_pid2630.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
En danger, la chance est plus élevée pour obtenir un SIGSEGV qu'une exécution normale.
@Karussell Vous êtes plus susceptible d'obtenir un Sigbus à moins que vous accédez à la première page par accident, pas que c'est mieux.
@Peter: Pouvez-vous partager le nom pleinement qualifié pour champ ? Je reçois 11 options lorsque vous faites CTRL + Maj + O dans mon espace de travail Eclipse.
@Pk 'c'est dans java.lang.reflect
@Peter - Le code a fonctionné mais je n'ai pas pu voir la JVM s'est écrasé. Utilisation JDK1.7_U51 sur Windows 8 x64.
reproduit ceci en Java 8
Crashing L'application peut être effectuée à l'aide de l'OutOfMemoryError également.
java.lang.OutOfMemoryError}}}
Pour écraser l'ensemble de l'ordinateur, je ferais:
public static void crashComputer() {
while(true) {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
while(true) {
crashComputer();
}
}
});
thread.start();
}
}
public static void crashJVM() {
while(true)
crashJVM();
}
Non, cela ne Crash Le VM. Vous pouvez facilement déclencher un débordement de mémoire avec une boucle infinie.
System.exit () Termine Just Terminate VM - Ceci est une question en double - regardez ici Comment écrases-tu une JVM?Je peux inclure le code pendant mon développement.
Cette question d'entretien n'a pas de sens sur la première place!
Ouais mais le débordement de la mémoire est un crash de programme, pas un crash de VM. Pour avoir un véritable crash de JVM, vous devrez trouver et utiliser un bogue JVM actuel - évidemment, le Crash JVM ne fait pas partie du temps d'exécution attendu normal.
@ Thor84no, n'est pas d'accord avec vous plus.