Bonjour !
 
Je suis entrain de devenir fou avec le garbage collector de java et l'impossibilité de faire un free à la main...
 
Depuis que j'ai intégré le mode client / serveur dans mon projet, la mémoire augmente inexorablement au cours de l'exécution. Le problème vient à priori des requètes qu'il ne libère pas après les avoir envoyé et lu.
 
Le code d'envoi de requete du serveur :
 

 
Le constructeur utilisé :
 

 
En gros, les méthodes toString et getListe créent respectivement un new String ou new LinkedList, les remplissent puis les return.
 
Si j'ai bien compris le principe du garbage collector, ces string et liste n'étant (à priori) référencés que par la requete (et par une variable locale dans les toString et getListe, mais qui logiquement sont détruites à la fin de la fonction), à la fin de envoyerRequete, il devrait libérer requeteSituation et tout ce qu'elle contient.
 
Or ce n'est pas le cas, les données stagnent quelque part, où et pourquoi je ne sais pas... J'ai tenté de mettre un requeteSituation = null à la fin de la fonction, aucun résultat (logique...), j'ai tenté de ne faire qu'une fois le new CRequeteSituation() en mettant cette requete en donnée membre du serveur et en utilisant dans envoyerRequete() une fonction integrer() avec exactement le mm code que le constructeur, mais ça ne marche plus (pb avec la serialization et les références je suppose).
 
Bref quelqu'un aurait une solution pour libérer des choses à la main, ou verrait immédiatement l'erreur dans mon sale code de noob ? Merci d'avance...

fais pêter tout le code.
 
 
mais sache une chose : si tu avais fait un free, tu aurais déclenché un bug.

hum et donne-nous les chiffres de consomation mémoire et les arguments passés à la JVM stp ...

Pas d'arguments spéciaux utilisés (pas que je sache du moins, à noter que j'utilise netBeans...).
 
Conso mémoire : ça commence à 40Mo et au bout de 10mn de jeu en gros, ça atteind 90Mo et ça bug...
 
J'ai oublié de dire que j'avais fait un test pour être sûr que l'augmentation mémoire venait des requètes : j'ai envoyé les requètes à une fréquence 10 fois inférieure, et le problème ne se posait effectivement plus (même s'il aurait sûrement réapparu après une centaine de minutes).
 
Le reste du code qui peut jouer :
 
La fonction toString :
 

 
Fonction getList :
 

 
getEnvoyable() renvoit un newCPersonnageEnvoyable qui contient les données à envoyer du Pacman.
 
Et la récupération de la requete côté client :
 

 
Le setCarte n'alloue rien, il écrase les données de l'ancienne matrice par les nouvelles, idem pour les refresh qui écrasent les anciennes données des personnages par les nouvelles.

je te demande pas ce TU penses qui pourrait jouer, si tu avais trouvé le pb, tu ne serais pas là, mais je te demande de tout nous montrer pour que NOUS évaluions la chose.

Ben en même temps je me vois mal mettre les 61 classes ici Donc autant que possible je met les parties de code qui sont susceptibles de poser problème (pouvoir localiser le problème n'implique pas de savoir le résoudre).
 
Je viens de tester en + de ne plus envoyer de requete, de faire simplement
 

 
C'est à dire exactement la même chose qu'avant (les appels à getCarte et getListe à la même fréquence), mais sans envoyer de requète. Et là, la mémoire est stable.
 
Donc je pense vraiment que ça vient de ces requetes que java ne libère pas pour une raison inconnue, et il ne libère donc pas non plus leur contenu (le string et les listes). Reste à savoir pourquoi...

et c'est le mosieur sur le forum de Sun qui gagne une tringle à rideaux :
quand on fait de la sérialisation d'objets on est obligé de garder l'ensemble des objets passés dans le stream pour gérer les références circulaires.
 
donc soit tu fais risette, soit tu fermes le stream quand tu n'en a plus besoin, mais il faut vider cette collection.

Pis ta fonctions toString elle doit fabriquer des centaines vorie des milliers d'objet, faudrait voir à utiliser un StringBuffer plutôt

En fait en pratique j'utilise un stringBuilder, la différence de perf avec un string est impressionante (pourquoi stringBuilder je ne sais pas, c'est pas moi qui ai codé cette partie en fait - le réseau non plus d'ailleurs, c'est un projet en groupe de 7). Mais bon c'est clair que ça doit pas être optimisé du tout, on débutait tous en java.
 
Quoiqu'il en soit entre temps j'ai réglé le problème, effectivement avec un reset :
 

 
M'en vais taper sur les doigts à celui qui a fait le réseau qui me l'a livré avec deux semaines de retard pour bien tout étudier en profondeur et résultat il n'a pas géré cette subtilité    
 
Merci pour l'aide en tout cas