Java VM se déconnectant soudainement sans raison apparente

Question

J'ai un problème avec mon programme Java qui se ferme soudainement, sans aucune exception levée ou le programme se terminant normalement. J'écris un programme pour résoudre Project Euler14th problem. Voilà ce que je suis:

private static final int INITIAL_CACHE_SIZE = 30000; 
private static Map<Long, Integer> cache = new HashMap<Long, Integer>(INITIAL_CACHE_SIZE); 

public void main(String... args) { 
    long number = 0; 
    int maxSize = 0; 

    for (long i = 1; i <= TARGET; i++) { 
     int size = size(i); 
     if (size > maxSize) { 
      maxSize = size; 
      number = i; 
     } 
    } 
} 
private static int size(long i) { 
    if (i == 1L) { 
     return 1; 
    } 
    final int size = size(process(i)) + 1; 
    return size; 
} 

private static long process(long n) { 
    return n % 2 == 0 ? n/2 : 3*n + 1; 
} 

Cela fonctionne très bien, et se termine correctement en 5 secondes avec un objectif de 1 000 000.

Je voulais optimiser en ajoutant un cache, donc je changé la méthode de taille à ceci:

private static int size(long i) { 
    if (i == 1L) { 
     return 1; 
    } 
    if (cache.containsKey(i)) { 
     return cache.get(i); 
    } 
    final int size = size(process(i)) + 1; 
    cache.put(i, size); 
    return size; 
} 

maintenant, quand je le lance, il arrête simplement (sorties de processus) quand je reçois à 555144. même nombre chaque fois. Aucune exception, erreur, plantage Java VM ou tout est levé.

Modification de la taille du cache ne semble pas avoir d'effet non plus, alors comment le cache introduction peut provoquer cette erreur?

Si j'appliquer la taille du cache pour être non seulement initial, mais permanent comme ceci:

if (i < CACHE_SIZE) { 
     cache.put(i, size); 
    } 

le bug ne se produit plus. Modifier: Lorsque je définis la taille du cache sur 2M, le bogue commence à s'afficher à nouveau.

Quelqu'un peut-il reproduire cela, et peut-être même donner une suggestion pour expliquer pourquoi cela se produit?

Answer 1

Ceci est simplement une OutOfMemoryError qui ne sont pas en cours d'impression. Le programme s'exécute correctement si je définis une taille de tas élevée, sinon il se ferme avec un OutOfMemoryError non ouvert (facile à voir dans un débogueur, cependant).

Vous pouvez vérifier et obtenir une décharge de tas (ainsi que l'impression qu'un OutOfMemoryError a eu lieu) en passant cette arg machine virtuelle Java et de refaire votre programme:

-XX:+HeapDumpOnOutOfMemoryError

Avec cela, il sera alors imprimer quelque chose à cet effet:

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid4192.hprof ...
Heap dump file created [91901809 bytes in 4.464 secs]

Bump votre taille de tas avec, disons, -Xmx200m et vous n'aurez pas un problème - au moins pour TARGET = 1000000.

Answer 2

Si votre processus Java se bloque soudainement, il se peut qu'une ressource soit dépassée. Comme la mémoire. Vous pouvez essayer de définir un tas max plus élevé.

Answer 3

Voyez-vous un Heap Dump généré après le crash? Ce fichier devrait être dans le répertoire courant pour votre JVM, c'est là que je chercherais plus d'informations.

Answer 4

Je reçois une erreur OutOfMemory sur le cache.put (i, size);

Pour obtenir l'erreur exécutez votre programme en éclipse en utilisant le mode de débogage il apparaîtra dans la fenêtre de débogage. Il ne produit pas de trace de pile dans la console.

Answer 5

Il semble que la JVM elle-même se bloque (c'est le premier réflexe quand votre programme meurt sans aucune allusion d'exception). La première étape d'un tel problème consiste à passer à la dernière révision de votre plate-forme. La machine virtuelle Java doit vider le tas dans un fichier .log du répertoire dans lequel vous avez démarré la machine virtuelle Java, en supposant que votre niveau d'utilisateur dispose des droits d'accès à ce répertoire. Cela étant dit, certaines erreurs OutOfMemory ne sont pas signalées dans le thread principal, donc à moins que vous n'essayiez try/catch (Throwable t) et que vous en obteniez un, il est difficile de vous assurer que vous n'êtes pas réellement juste à court de mémoire. Le fait qu'il n'utilise que 100 Mo pourrait simplement signifier que la JVM n'est pas configurée pour utiliser plus. Cela peut être changé en changeant les options de démarrage à la JVM à -Xmx1024m pour obtenir un gig de mémoire, pour voir si le problème va n'importe où.

Le code pour faire les prises d'essai devrait être quelque chose comme ceci:

public static void main(String[] args) { 
    try { 
     MyObject o = new MyObject(); 
     o.process(); 
    } catch (Throwable t) { 
     t.printStackTrace(); 
    } 
} 

Et tout dans la méthode du processus et ne stocke pas votre cache statique, de cette façon si l'erreur se produit à l'instruction catch l'objet est hors de portée et peut être collecté, libérant suffisamment de mémoire pour permettre l'impression de la trace de la pile. Aucune garantie que cela fonctionne, mais cela donne un meilleur coup.

Answer 6

La méthode récursive size() n'est probablement pas un bon endroit pour effectuer la mise en cache. J'ai mis un appel à cache.put (i, size); à l'intérieur de la boucle for principale() et cela fonctionne beaucoup plus rapidement. Sinon, je reçois également une erreur MOO (plus d'espace de tas). Editer: Voici la source - la récupération du cache est en taille(), mais le stockage est effectué dans main().

public static void main(String[] args) { 
    long num = 0; 
    int maxSize = 0; 

    long start = new Date().getTime(); 
    for (long i = 1; i <= TARGET; i++) { 
     int size = size(i); 
     if (size >= maxSize) { 
      maxSize = size; 
      num = i; 
     } 
     cache.put(i, size); 
    } 

    long computeTime = new Date().getTime() - start; 
    System.out.println(String.format("maxSize: %4d on initial starting number %6d", maxSize, num)); 
    System.out.println("compute time in milliseconds: " + computeTime); 
} 

private static int size(long i) { 
    if (i == 1l) { 
     return 1; 
    } 

    if (cache.containsKey(i)) { 
     return cache.get(i); 
    } 

    return size(process(i)) + 1; 
} 

Notez que en supprimant la cache.put() appeler de la taille(), il ne met pas en cache toutes les tailles calculée, mais elle évite également re-mise en cache une taille calculée précédemment. Cela n'affecte pas les opérations de hashmap, mais comme le fait remarquer akf, il évite les opérations autoboxing/unboxing d'où provient votre tueur de tas. J'ai aussi essayé "if (! ContainsKey (i)) {cache.put() etc" dans size() mais malheureusement, il manque aussi de mémoire.

Answer 7

Une différence significative entre les deux implémen- tations de size(long i) est la quantité d'objets que vous créez.

Dans la première implémentation, aucun Objects n'est créé. Dans la seconde vous faites énormément d'autoboxing, en créant un nouveau Long pour chaque accès de votre cache, et en mettant de nouveaux Long s et de nouveaux Integer s sur chaque modification.

Cela expliquerait l'augmentation de l'utilisation de la mémoire, mais pas l'absence d'un OutOfMemoryError. Augmenter le tas permet de le compléter pour moi.

De this Sun aritcle:

The performance ... is likely to be poor, as it boxes or unboxes on every get or set operation. It is plenty fast enough for occasional use, but it would be folly to use it in a performance critical inner loop.