Java Heap Space : bien gérer l'exception

Version imprimable

Voir 40 message(s) de cette discussion en une page

bonjour,

j'ai une application qui peut dans certains cas provoquer une erreur de type "java.lang.OutOfMemoryError: Java heap space". Je voudrais gérer convenablement cette erreur : dans mon cas il s'agirait de fermer simplement l'application.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 try { // mon code qui provoque l'erreur } catch (OutOfMemoryError ex) { JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE); Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex); System.gc(); System.exit(-1); } catch (Error ex) { JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE); Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex); System.gc(); System.exit(-1); } catch(Exception ex) { JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE); Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex); System.gc(); System.exit(-1); }
Ce code fonctionne très bien mais toutefois, je voudrais savoir si ma manière dé gérer cette erreur est "propre", à savoir :
- j'appelle le carbage collector (pour détruire les objets et vider la mémoire :question:) ;
- je fais un exit(-1) : je ne devrais pas plutôt faire un dispose() :question:

:merci: pour vos conseils.

13/01/2010, 23h27
ttttnht

Bonjour,

Normalement avec Java on n'a pas besoin de gc (c'est Java qui gere lui-meme ce genre de choses).

Pour dispose: Java gere ca normalement tu n'as pas besoin de le faire.

Quant au exit avec -1 si tu veux retourner un code de retour comme sous *nix.
14/01/2010, 00h29
gronono

Si tu as OutOfMemoryError, tu arrives encore à créer des objets ?

Salut,

Citation:

Envoyé par ttttnht

Normalement avec Java on n'a pas besoin de gc (c'est Java qui gere lui-meme ce genre de choses).

+1
Dans 99% des cas le System.gc() est contre-productif et peut engendrer de mauvaise performance... en plus d'être inutile !

C'est le cas ici car le GC va faire tout son possible pour libérer la mémoire avant de remonter une OutOfMemoryError.
Et à la fin de l'application la JVM libère toute la mémoire d'un bloc (ce qui est bien plus performant).

Citation:

Envoyé par ttttnht

Quant au exit avec -1 si tu veux retourner un code de retour comme sous *nix.

Le exit() suffit amplement pour fermer l'application et tous ses éléments graphiques. Il me semble toutefois qu'on utilise en général un code de retour positif, mais c'est un détail...

Maintenant il est peut-être préférable de fermer explicitement certaines ressources qui pourrait se retrouver bloquer pendant un certain temps (comme une connexion réseau par exemple), mais il n'y a pas de problème pour tout ce qui concerne l'interface utilisateur...

Mais au cas où tu tu peux utiliser les shutdown hook, qui seront exécuté juste avant la fin de ton application quelque soit la manière dont elle se termine :
Code:

1 2 3 4 5 6 7 Runtime.getRuntime().addShutdownHook(new Thread() { @Override public void run() { // System.out.println("Bye bye..."); } });
Citation:

Envoyé par gronono

Si tu as OutOfMemoryError, tu arrives encore à créer des objets ?

Bonne remarque !

En fait cela dépend de l'état de ton application. Prenons par exemple une application limité à 64Mo.

Si tu utilises réellement 32Mo et que ton application tente d'allouer encore 40 Mo cela va provoquer une OutOfMemoryError, mais en sortie de cela ton application se retrouve à nouveau à 32Mo (les 40 n'ont pas pu être alloué) et tu peut donc allouer de nouveaux objets. Toutefois il n'est pas vraiment conseiller de continuer l'application comme si de rien n'était car il y a de forte chance que cela se reproduise...

Maintenant si petit à petit ton application approche des 64Mo d'utilisation réelles, alors tu peux en effet rencontrer des problèmes à nouveau jusque dans le code de traitement de ton exception (par exemple car il n'y a toujours pas assez de mémoire pour le JOptionPane). Cela peut être problématique car alors le exit() ne serait pas exécuté, et l'application pourrait continuerait de tourner... :?

En fait pour gérer ce cas extrême il faut utiliser un try/finally :
Code:

1 2 3 4 5 6 try { JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE); Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex); } finally { System.exit(1); }
Maintenant il y a deux point qui me gène dans ton code :

Les 3 blocs de traitement des exceptions identique !
Le fait que tu traites des Errors directement dans ton code.

Les Errors correspondent à des problèmes graves, et ne devrait pas vraiment être traitées...

Si tu es en Java 5.0 il est préférables d'utiliser les UncaughtExceptionHandler, qui te permettent de traiter les exceptions qui ne sont pas traitées :
Code:

1 2 3 4 5 6 7 8 9 10 11 Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() { @Override public void uncaughtException(Thread t, Throwable ex) { try { JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE); Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex); } finally { System.exit(1); } } });
a++

Citation:

Envoyé par adiGuba

Dans 99% des cas le System.gc() est contre-productif et peut engendrer de mauvaise performance... en plus d'être inutile !

C'est le cas ici car le GC va faire tout son possible pour libérer la mémoire avant de remonter une OutOfMemoryError.
Et à la fin de l'application la JVM libère toute la mémoire d'un bloc (ce qui est bien plus performant).

ok donc je supprime l'appel à System.gc() :D

Citation:

Envoyé par adiGuba

Le exit() suffit amplement pour fermer l'application et tous ses éléments graphiques. Il me semble toutefois qu'on utilise en général un code de retour positif, mais c'est un détail...

Maintenant il est peut-être préférable de fermer explicitement certaines ressources qui pourrait se retrouver bloquer pendant un certain temps (comme une connexion réseau par exemple), mais il n'y a pas de problème pour tout ce qui concerne l'interface utilisateur...

Justement mon application créé 2 thread. Ils seront détruits lors de l'appel de exit() ?
Par ailleurs, si j'ai une connexion réseau et qu'une erreur comme celle-ci se produit, sera-t-elle fermée lors de l'appel de exit() ?
Citation:
Envoyé par adiGuba
Maintenant si petit à petit ton application approche des 64Mo d'utilisation réelles, alors tu peux en effet rencontrer des problèmes à nouveau jusque dans le code de traitement de ton exception (par exemple car il n'y a toujours pas assez de mémoire pour le JOptionPane). Cela peut être problématique car alors le exit() ne serait pas exécuté, et l'application pourrait continuerait de tourner...

En fait pour gérer ce cas extrême il faut utiliser un try/finally :
Code:

1 2 3 4 5 6 try { JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE); Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex); } finally { System.exit(1); }
Les Errors correspondent à des problèmes graves, et ne devrait pas vraiment être traitées...

Si tu es en Java 5.0 il est préférables d'utiliser les UncaughtExceptionHandler, qui te permettent de traiter les exceptions qui ne sont pas traitées :
Code:

1 2 3 4 5 6 7 8 9 10 11 Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() { @Override public void uncaughtException(Thread t, Throwable ex) { try { JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE); Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex); } finally { System.exit(1); } } });
Il n'y a pas de catch() dans tes exemples :koi:

J'ai placé un finally{...} après le try et le exit est exécuté même si aucune erreur est levée... J'ai raté un truc ?

14/01/2010, 22h38
Baptiste Wicht

Citation:

Envoyé par Auteur

Justement mon application créé 2 thread. Ils seront détruits lors de l'appel de exit() ?

Oui, tout les threads sont détruits par exit().

Citation:

Envoyé par Auteur

Par ailleurs, si j'ai une connexion réseau et qu'une erreur comme celle-ci se produit, sera-t-elle fermée lors de l'appel de exit() ?

Non, c'est à toi de gérer ce cas-là, les ressources ne sont pas automatiquement fermées.

Citation:

Envoyé par Auteur

Il n'y a pas de catch() dans tes exemples :koi:

J'ai placé un finally{...} après le try et le exit est exécuté même si aucune erreur est levée... J'ai raté un truc ?

Tu n'en a pas pas besoin.

Il s'agit d'un try/finally. Ce qui va dire que ton exit(-1) sera éxécuté même si une erreur survient dans le corps du try, dans cet exemple s'il n'y a plus assez de mémoire pour créer un nouvel objet et pour éxécuter JOptionPane, ton programme va quand même correctement quitter.
15/01/2010, 10h16
Auteur

Citation:

Il s'agit d'un try/finally. Ce qui va dire que ton exit(-1) sera éxécuté même si une erreur survient dans le corps du try, dans cet exemple s'il n'y a plus assez de mémoire pour créer un nouvel objet et pour éxécuter JOptionPane, ton programme va quand même correctement quitter.

oui mais là même s'il n'y a pas d'erreur dans le try, le finally est exécuté :?

Citation:

Envoyé par Baptiste Wicht

Oui, tout les threads sont détruits par exit().

Citation:

Envoyé par Auteur

Par ailleurs, si j'ai une connexion réseau et qu'une erreur comme celle-ci se produit, sera-t-elle fermée lors de l'appel de exit() ?

Non, c'est à toi de gérer ce cas-là, les ressources ne sont pas automatiquement fermées.

ah.... :aie:
Ma connexion réseau est gérée justement par les thread (à cause de la méthode accept() des objets socket qui est bloquante). Du coup je dois explicitement faire un

Code:

monThread.join()

avant l'appel de ma fonction exit() ?

Dans mon premier message j'hésitais entre this.dispose() qui ferme mon application (en stoppant les thread également) et System.exit().
Les deux méthodes sont équivalentes finalement ? J'ai l'impression qu'un System.exit() est plus "bourrin". :aie:
15/01/2010, 10h43
adiGuba

Citation:

Envoyé par Auteur

oui mais là même s'il n'y a pas d'erreur dans le try, le finally est exécuté :?

C'est ce qu'on veut faire non : Afficher un message d'erreur et quitter proprement.

:arrow: Si l'application se retrouve dans un état si extrême qu'on n'arrive même pas à afficher le message d'erreur, on quittera quand même l'application.

Citation:

Envoyé par Auteur

ah.... :aie:
Ma connexion réseau est gérée justement par les thread (à cause de la méthode accept() des objets socket qui est bloquante). Du coup je dois explicitement faire un

Code:

monThread.join()

avant l'appel de ma fonction exit() ?

Le join() est inutile...
Ce que tu peux faire c'est fermer la socket explicitement.

Citation:

Envoyé par Auteur

Dans mon premier message j'hésitais entre this.dispose() qui ferme mon application (en stoppant les thread également) et System.exit().
Les deux méthodes sont équivalentes finalement ? J'ai l'impression qu'un System.exit() est plus "bourrin". :aie:

Tu peux faire les dispose() si tu veux, ainsi que toutes les libérations des ressources externes (sockets, JDBC, etc.), mais je pense qu'il est important de finir par un exit().

:arrow: Les dispose() permettent de libérer les ressources alloués aux éléments graphiques, et non pas de terminer l'application.

Maintenant c'est vrai que lorsque tu n'as plus aucune fenêtre et que l'EDT est le seul thread non-daemon, il se termine de lui même et met fin à l'application. Mais il faut être sûr qu'il n'y a aucun autre thread vivant !

Pourrais-tu garantir cela dans le cas d'un plantage de ton application ?

a++
15/01/2010, 13h33
tchize_

Citation:

Il n'y a pas de catch() dans tes exemples

J'ai placé un finally{...} après le try et le exit est exécuté même si aucune erreur est levée... J'ai raté un truc ?

oui, tu as raté qu'on est dans le UncaughtExceptionHandler, qui traite toutes les exceptions qui sont remontées au delà de ton run(). Quand on est dans ce handler, ca signifie que le thread est déjà mort. On est donc déjà dans un cas critique, il est donc normal de vouloir quitter quoi qu'il arrive.

Citation:

Par ailleurs, si j'ai une connexion réseau et qu'une erreur comme celle-ci se produit, sera-t-elle fermée lors de l'appel de exit() ?

Lorsqu'une application se termine, c'est le travail de l'OS de libérer toutes les ressource. Java ne va pase explicitement fermer tes sockets, tes fenetres, tes threads et te file handle. Pourtant, l'os va tout détruire comme un grand lorsque l'application quitte (plus de fenetre, plus de sockets, plus de threads, réattacher les fils à un autre parent, plus de threads). Une application ne peut pas garder des ressources au delà de sa durée de vie.

Je viens de comprendre :aie:
Code:

1 2 3 4 5 6 try { JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE); Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex); } finally { System.exit(1); }
Je dois placer ce bout de code dans le catch :boulet:
J'avais simplement rajouté le finally après mon try{} catch{} :oops: :oops:

Citation:

Envoyé par tchize_

oui, tu as raté qu'on est dans le UncaughtExceptionHandler, qui traite toutes les exceptions qui sont remontées au delà de ton run(). Quand on est dans ce handler, ca signifie que le thread est déjà mort. On est donc déjà dans un cas critique, il est donc normal de vouloir quitter quoi qu'il arrive.

ok :D

Citation:

Envoyé par tchize_

Lorsqu'une application se termine, c'est le travail de l'OS de libérer toutes les ressource. Java ne va pase explicitement fermer tes sockets, tes fenetres, tes threads et te file handle. Pourtant, l'os va tout détruire comme un grand lorsque l'application quitte (plus de fenetre, plus de sockets, plus de threads, réattacher les fils à un autre parent, plus de threads). Une application ne peut pas garder des ressources au delà de sa durée de vie.

Donc pas besoin de fermer mes sockets explicitement ???

Citation:

Envoyé par adiGuba

Ce que tu peux faire c'est fermer la socket explicitement.

Même si a priori c'est plus propre...

15/01/2010, 14h12
tchize_

Citation:

Envoyé par Auteur

Donc pas besoin de fermer mes sockets explicitement ???

Non je vois d'ailleurs pas l'intéret de nettoyer explicitement quelque chose qui va quand meme etre nettoyé de la meme manière par l'OS quelques millisecondes plus tard.

Maintenant, si t'as des protocoles spécifiques avec tes client tu peux les utiliserp our fermer "propremen" au niveau protocole plutot que de leur couper abuptement le cordon, mais c'est risqué (tu sais pas dans quel état est ta jvm)

L'appel a System.gc() n'est pas direct c'est juste une directive, Après on ne sait pas quand exactement il va passer, pour cela vaut mieux attendre un petit instant pour lui donné une chance de passé. Voilà une autre façon de faire:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
try
{
    // mon code qui provoque l'erreur
 
}
catch (OutOfMemoryError ex)
{
   System.gc();
    //Retenter plusieurs fois le même code. Si toujours la même erreur   alors on sort définitivement!	
boolean error = true;
for(int i=0; i< 10; i++) {
   try {
        Thread.sleep(500);
        //rééxécuter le même code
       error = false; 
       break;
    } catch(OutOfMemoryError me) {
    } catch(Exception ignored) {}
 }
if (error)  {
try {   
JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE);
	Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex);
}finally {
	System.exit(-1);
 }
}
}
catch (Throwable e)
{
     //Comme l'a spécifié adiguba avec un try - finally
}
 
}

15/01/2010, 15h01
adiGuba

:arrow: Il ne faut pas utiliser System.gc() !!!!

a++
15/01/2010, 15h41
Auteur

Plusieurs remarques sur ton code hibour (en dehors du fait que tu utilises System.gc()) :

1- Si j'ai un heap memory qui me dis que je pourrais encore créer un entier i et un booléen error ?
2- Es-tu sûr qu'attendre 500ms une action de la jvm est suffisant, puisqu'en théorie on ne sait jamais quand cette action aura lieu ?
3- Quel intérêt de ré-exécuter le code qui a provoquer l'erreur ? :koi:
15/01/2010, 16h00
Uther

Je suis d'accord su le fait que le code d'attente de hibour ne sert a rien.

La jvm fait systématiquement un GC complet avant de lancer une OutOfMemoryError.
15/01/2010, 16h32
hibour

Puis-je avoir une référence de la spécification java qui dit que la JVM appel le GC juste avant de lancer un OutOfMemoryError!
Le code que j'ai fourni s'inspire d'un code de l'API java que j'ai vu dans l'une des classe XXXBuffer (écrite par un Pro de SUN). Je suis assez certain que le fait de donner une chance au GC de faire le ménage de la mémoire peut libérer un espace mémoire du coup on peut retenter une allocation mémoire.:mouarf:
15/01/2010, 16h46
tchize_

api java:

Citation:

public class OutOfMemoryError
extends VirtualMachineError

Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

Citation:

The name gc stands for "garbage collector". The virtual machine performs this recycling process automatically as needed, in a separate thread, even if the gc method is not invoked explicitly.

Les classes de base java pour certaines sont vieille et n'ont pas été revisitées depuis les première versions de java, le GC au début n'était pas ce qu'il est maintenant, et les appel au gc avaient une justification au tout début. Maintenant ce n'est plus le cas.

De plus, quelque part dans les specs, il est mentionné clairement la marche a suivre pour allouer de la mémoire, et ca stipuel clairement les étape suivies en interaction avec le gc. Tu y verra donc que, si t'as le outofmemory, c'est qu'il est vraiment pas possible de trouver la mémoire.
15/01/2010, 17h06
hibour

tchize:La classe java.nio.XXXBuffer est une classe à partir de java 1.4 elle n'est pas si vieille.
Ce que tu as fourni n'est qu'une javadoc c'est pas une Specification.
15/01/2010, 17h24
adiGuba
Pourtant la javadoc de OutOfMemoryException est tout à fait correcte !

Exécutes ce code avec l'option -verbose:gc pour suivre le comportement du GC :
Code:

1 2 3 public static void main(String[] args) throws Exception { byte[] bytes = new byte[Integer.MAX_VALUE]; }
Tu verras qu'il tente des FullGCs avant de remonter l'exception.

Maintenant ce n'est pas parce que c'est utilisé dans uen code en provenance de chez Sun que c'est forcément correct ! Au contraire l'API comporte un paquet de bug ou de code incorrect !

a++
15/01/2010, 17h55
hibour

C'est clair qu'on ne peut pas allouer plus de mémoire qu'en on a à notre possession!
Dans le cas d'une application il ya des objets (références) qui ne sont plus atteignable et que le gc peut récupérer. Si à un instant T on veut allouer une quantité de mémoire raisonnable (pas comme dans ton code) alors peut être le fait d'attendre un peu le GC ça peut aider à récupérer un peu de mémoire et du coup ça peut fonctionner..

Voir 40 message(s) de cette discussion en une page