IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage Java Discussion :

A la recherche de memory leaks: un mauvais emploi de String pourrait-il m'y conduire?


Sujet :

Langage Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre très actif

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    608
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 608
    Par défaut A la recherche de memory leaks: un mauvais emploi de String pourrait-il m'y conduire?
    Bonjour,

    Ca y est, je l'ai eu, mon premier "PermGen space: Out of memory error".

    Et si j'ai en conséquence augmenté la quantité de mémoire alloué à cette espace et au serveur en général, cela n'empêche pas qu'il est temps d'investiguer.

    Le problème: l'application est logée sur un serveur JBoss, qui a donc fini par "céder", et ses métriques sont:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    packages   Classes Functions      NCSS  Javadocs | per
    -------------------------------------------------------------
       263.00   1168.00   6397.00  55191.00   7439.00 | Project
    Ce qui ne va pas permettre de cerner rapidement mon problème.

    Le seul réflexe que j'ai eu pour le moment est de lâcher une commande jmap.
    Voici ce qu'elle me dit:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    D:\Dev\Java>jmap -histo 3860
     
     num     #instances         #bytes  class name
    ----------------------------------------------
       1:        398248       45741728  [C
       2:         39275       32169496  [B
       3:        125854       16230024  <constMethodKlass>
       4:        661764       15882336  java.lang.String
       5:         87741       14406352  [I
       6:        374409       11981088  java.util.TreeMap$Entry
       7:        125854       10073928  <methodKlass>
       8:        100329        9216144  [Ljava.util.HashMap$Entry;
       9:        187949        8705192  <symbolKlass>
      10:        306050        7345200  java.util.HashMap$Entry
      11:         12994        7266696  <constantPoolKlass>
      12:         12994        5621016  <instanceKlassKlass>
      13:         64130        5130400  java.lang.reflect.Method
      14:         71800        4555408  [Ljava.lang.Object;
      15:         10893        4171728  <constantPoolCacheKlass>
      16:         84360        4049280  java.util.TreeMap
      17:        109670        3509440  java.util.concurrent.ConcurrentHashMap$Segment
      18:         86605        3464200  java.util.HashMap
      19:        122611        2942664  java.util.concurrent.locks.ReentrantLock$NonfairSync
      20:         46277        2591512  org.jboss.virtual.plugins.context.zip.ZipEntryHandler
      21:         46024        2577344  java.util.zip.ZipEntry
      22:         39664        2538496  org.jboss.mx.server.InvocationContext
      23:         76985        2463520  java.util.LinkedHashMap$Entry
      24:        109724        2446640  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
      25:         93435        2242440  java.util.concurrent.ConcurrentHashMap$HashEntry
      26:        132884        2126144  org.jboss.logging.log4j.Log4jLoggerPlugin
      27:        132884        2126144  org.jboss.logging.Logger
      28:         27580        1544480  java.net.URL
      29:         13814        1326144  java.lang.Class
      30:          4554        1306392  <methodDataKlass>
      31:         80191        1283056  javax.management.modelmbean.DescriptorSupport
      32:         50428        1210272  java.util.ArrayList
      33:         18575        1188800  java.util.regex.Matcher
      34:         46404        1113696  org.jboss.virtual.plugins.context.zip.ZipEntryContext$EntryInfo
      35:         16896        1042960  [S
      36:         20833         892656  [[I
      37:         47229         847696  [Ljava.lang.String;
      38:         20546         821840  javax.management.modelmbean.ModelMBeanOperationInfo
      39:         16907         811536  com.sun.tools.javac.zip.ZipFileIndexEntry
      40:         42662         682592  java.util.TreeMap$EntrySet
      41:         17036         681440  org.jboss.mx.interceptor.AttributeDispatcher
      42:         17036         681440  org.jboss.mx.interceptor.PersistenceInterceptor
      43:         28354         680496  java.lang.ref.WeakReference
      44:         20546         657472  org.jboss.mx.interceptor.ReflectedDispatcher
      45:         13528         649344  java.util.LinkedHashMap
      46:          1177         562088  [J
      47:          7139         552896  [Ljava.util.concurrent.ConcurrentHashMap$Segment;
     
     (Total final: 250 Ko environ de RAM, après 5000 lignes décrites).
    Pour le moment, les objets de mon application, qui sont dans des packages particuliers autres que com, org, java, ne sont pas mentionnés dans cette liste. Mais par incidence, ils créent nessairement un grand nombre des objets java.*.* vus ici.
    Cependant, dans cette liste je dois considérer que je vois autant des objets créés par JBoss (mon serveur d'application) que par moi.

    Mais tout cela étant dit, il y a beaucoup de Strings! Vraiment beaucoup.

    Et si je peux imaginer avoir des Vector ou des Hashtable qui n'auraient pas été vidés convenablement, je me demande si je ne ferais pas une faute générale d'emploi de la classe String. J'écris cela, même si je ne vois pas du tout comment cela pourrait arriver, en dehors de la stocker dans un objet membre (statique surtout).


    En vous remerciant pour vos avis,

    Grunt.

  2. #2
    Membre expérimenté
    Profil pro
    Inscrit en
    Mai 2009
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2009
    Messages : 156
    Par défaut
    Les classes C et B font t'elles emploit de String, si telle est le cas c'est probablement de l'utilisation des instances de ces classe que vient le problème plutôt que de l'utilisation des String.

  3. #3
    Membre éprouvé
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    104
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Mars 2004
    Messages : 104
    Par défaut
    Salut,

    attention à ne pas confondre les zones mémoires. La zone perm gen est une zone statique qui contient des définitions de classes et méthodes et autres. Ce qui n'a rien avoir avec le heap qui contient les objets alloués.
    Cette erreur sur le perm gen space survient quand tu as beaucoup de classes ou d'utilisation d'AOP. Cela arrive aussi quand tu fais de nombreux redéploiement de ton application et que tu n'as pas configuré la JVM pour autoriser à vider cette zone.
    La taille par défaut est 64Mo, tu peux l'augmenter avec les paramètres -XX:MaxPermSize=96m et -XXermSize=72m par ex

Discussions similaires

  1. Réponses: 2
    Dernier message: 05/08/2007, 23h34
  2. [MFC] Thread & memory leaks
    Par Racailloux dans le forum MFC
    Réponses: 7
    Dernier message: 15/03/2005, 13h44
  3. Memory leak en C/C++
    Par Roswell dans le forum Autres éditeurs
    Réponses: 6
    Dernier message: 07/07/2004, 20h41
  4. [MFC] A la chasse au memory leak
    Par Yabo dans le forum MFC
    Réponses: 17
    Dernier message: 27/06/2004, 18h35
  5. Réponses: 7
    Dernier message: 26/02/2004, 10h32

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo