Avez vous trouvé des utilisations pratiques de System.gc() ? [Java] - Java - Programmation
Marsh Posté le 22-04-2002 à 16:45:49
j'ai eu un process récursif qui plantait dans de gros documents XML et mon collègue (qui a + d'xp que moi) l'a débuggé en forçant le passage du garbage collector.
après analyse, on a remarqué que la Hashtable que j'utilisais n'étais pas nettoyée vidée comme je croyais car Xerces laissait des références...
mais ça fait un bout de temps... je peux essayer de retrouver le cas si tu veux.
edit: donc vérifier la vie de tes variables... mais avec 11JVM ça doit pas être simple
[jfdsdjhfuetppo]--Message édité par TBone le 22-04-2002 à 16:47:15--[/jfdsdjhfuetppo]
Marsh Posté le 22-04-2002 à 16:49:30
DarkLord a écrit a écrit : Yep, Jusqu'à présent j'ai toujours pensé que l'appel à System.gc() était "inutile" dans le sens où le GC démarre qd même quand il l'a décidé ... Or ici, on a une grosse application avec 11 process différents (= 11 JVM) qui tourne 24/24. Et on remarque qu'au bout d'un certains temps elle se plante pour des raisons de mémoire visiblement. Or, pendant des périodes régulières elle est en standby et le GC devrait se lancer non? Votre avis ... |
regarde si la mémoire augmente continuellement, si c'est le cas c'est que des objets ne se detruisent pas comme il faut c'est clair...
avec une appli qui faisait plus de 1000 threads avec chacun d'eux plusieurs bjets, on avait pas besoin de ca, mais 11JVM... c'est la version 1.4 au fait?
Marsh Posté le 22-04-2002 à 16:50:22
TBone a écrit a écrit : edit: donc vérifier la vie de tes variables... mais avec 11JVM ça doit pas être simple |
Disons que on s'en sort relativement bien. Le problème est que j'ai un émulateur qui émule une machine IVR. Il recoit des fichiers XML demandant qu'un appel vocal ait lieu et renvoie une réponse bidon dans un temps pris au hasard entre 30 et 120 secs.
Donc chaque fois que je recois une requete j'inite un TimerTask qui a pour but d'envoyer, après X secs, la réponse bidon pour cette requete là. Je ne suis pas sur qu'il bousille mes timertasks a la fin ... (je ne garde aucune référence sur eux)
Marsh Posté le 22-04-2002 à 16:52:08
Citation : |
la mémoire descend à 3Mo libre puis elle remonte à 6Mo puis elle redescend à 5 puis elle remonte à 7. Tout le temps comme ça. Parfois ca plante mais je peux pas rester rivé sur mon top pendant 2 heures (le prob apparait lorsque ca tourne depuis plusieurs jours).
Citation : |
Non 1.3.1 sous linux
[jfdsdjhfuetppo]--Message édité par DarkLord le 22-04-2002 à 16:52:26--[/jfdsdjhfuetppo]
Marsh Posté le 22-04-2002 à 16:54:41
Marsh Posté le 22-04-2002 à 17:10:32
il parait que la 1.4 est plus rapide (instruction de base et natives) et reduit des bugs.. on sait jamais ca coute rien de l'installer
Marsh Posté le 22-04-2002 à 17:15:41
DLR a écrit a écrit : il parait que la 1.4 est plus rapide (instruction de base et natives) et reduit des bugs.. on sait jamais ca coute rien de l'installer |
C'est une RC1. On ne peut pas se permettre de mettre une RC1 dans un environnement de prod. Donc il faut qu'on trouve une autre solution pour l'instant
Marsh Posté le 22-04-2002 à 17:19:56
DarkLord a écrit a écrit : C'est une RC1. On ne peut pas se permettre de mettre une RC1 dans un environnement de prod. Donc il faut qu'on trouve une autre solution pour l'instant |
a merde c en prod
bon g rien dis...
revoyez l'algo et forcez les objets a null et stoppez bien tous les threads c tout ce que je vois
Marsh Posté le 22-04-2002 à 16:31:12
Yep,
Jusqu'à présent j'ai toujours pensé que l'appel à System.gc() était "inutile" dans le sens où le GC démarre qd même quand il l'a décidé ...
Or ici, on a une grosse application avec 11 process différents (= 11 JVM) qui tourne 24/24. Et on remarque qu'au bout d'un certains temps elle se plante pour des raisons de mémoire visiblement.
Or, pendant des périodes régulières elle est en standby et le GC devrait se lancer non?
Votre avis ...
---------------
Just because you feel good does not make you right