Thread Scope & GC

Bonjour,

J'ai deux questions à propos du comportement de java et du gc :

1) Si j'ai un thread qui tourne, et que je perds le pointeur dessus, est ce que le gc va attendre que le thread termine avant de le vider (sachant qu'il peut très bien ne jamais se terminer) ou alors il le vide direct, en plein fonctionnement ?

Qqun aurait une idée du comportement précis du truc ?

2) J'ai une formation c/c++ donc j'ai pris l'habitude de différencier les références (qui sont des const pointeurs en gros) et les pointeurs.

En java on appelle ça une référence pke on l'utilise avec un point, mais c'est la seule similarité avec la réference c++, vu que pour le reste ça se comporte comme un pointeur (on peut le mettre a null, le réutiliser, etc).

Jusqu'ici, tout va bien.

Maintenant, puisque tout est référence, j'ai une fonction comme ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public void fillThisString(String recipient) { recipient = "coucou"; }   public static main.... { String s = null; fillThisString(s); ... // s vaudra encore null }

---

En terme de référence/pointeur, s devrait être remplie, et surtout pas laissée à null !

Du coup, si je passe une référence en paramètre et que je veux qu'elle soit remplie, je dois faire comment ?

Merci

En Java, tout passage se fait par valeur. Quand tu passes un objet en paramètre, tu passes en fait la valeur de sa référence. Ainsi, si dans ta méthode tu fais un new d'un objet passé en paramètre, ton objet sera toujours null dans ton appelant. Par contre, si tu altères les propriétés de cet objet dans ta méthode, elles resteront modifiées lors de ton retour dans l'appelant.

Dans ton exemple, il suffit que ta méthode retourne la valeur :

Code:

---

1 2 3 4 5 6 7 8 9

public String fillThisString() { return "coucou"; }   public static main.... { String s = null; s = fillThisString(); }

---

Si tu veux vraiment passer par un paramètre, il faut alors utiliser un conteneur. Par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public String fillThisString(StringBuffer stb) { if(stb != null) { stb.setLength(0); stb.append("coucou"); } }   public static main.... { StringBuffer stb = new StringBuffer(""); fillThisString(stb); }

---

Pour ta question sur le Thread, tant que le thread est actif il ne sera pas récupéré par le GC.

Bulbo ;)

Citation:

---

Envoyé par bulbo

Pour ta question sur le Thread, tant que le thread est actif il ne sera pas récupéré par le GC.

Bulbo ;)

---

C'est pas dangereux de laisser tous ces threads dans la nature ? D'ailleurs, y a t il un moyen de récuperer un thread perdu ? (analyse de la vm ou quoi)

D'ailleurs, est ce possible de récuperer quoi que ce soit dans la vm si on a perdu le pointeur dessus ? (en supposant que le gc ne soit pas encore passé)

Citation:

---

Envoyé par Faiche

C'est pas dangereux de laisser tous ces threads dans la nature ? D'ailleurs, y a t il un moyen de récuperer un thread perdu ? (analyse de la vm ou quoi)

D'ailleurs, est ce possible de récuperer quoi que ce soit dans la vm si on a perdu le pointeur dessus ? (en supposant que le gc ne soit pas encore passé)

---

Non perdu c'est perdu, tu l'as dans le .. heu potiron :aie:

Pour les threads ya peut-être moyen mais je ne sais plus trop comment.. dans tout les cas pour moi la question ne se pose pas, si tu as besoin d'un Thread ou d'un objet mais que tu n'en a plus la référence c'est un problème de design. A toi de mettre en place un design qui te permette de fonctionner correctement..

Pour faire une analogie avec la vie réelle, si je balance a la poubelle le bout de chocolat et garde en main le papier d'alu (ce qui m'arrive régulièrement :aie:) je ne peux pas (veux pas, berk) récupérer le chocolat pour le becqueter..

Bulbo ;)

Salut,

Citation:

---

Envoyé par bulbo

Pour les threads ya peut-être moyen mais je ne sais plus trop comment..

---

Pour récupérer les threads actifs : Thread.enumerate()

Ou avec Java 5.0 de manière plus complète via les ThreadMXBean...


a++

Citation:

---

Envoyé par bulbo

si tu as besoin d'un Thread ou d'un objet mais que tu n'en a plus la référence c'est un problème de design.

---

C'était un cas théorique, mais de savoir qu'un programmeur java qui pense que le gc est magique peut balancer des zombies dans tous les sens, c'est interressant.

Thread.Enumerate() fait des copies des thread si j'ai bien lu ? Du coup, on a toujous les thread perdus qui tournent, mais maintenant on a en plus les versions copiées ?

D'ailleurs, les copies sont actives aussi ou non ?

ThreadMXBean me semble mieux pour récuperer les infos. Malheureusement ça ne permet pas de fermer tout le beau monde.

Il existe une lib qui apporte une autre implémentation des threads ? Et d'ailleurs il existe qqch qui permet de fouiller la vm etc ?

Citation:

---

Thread.Enumerate() fait des copies des thread si j'ai bien lu ? Du coup, on a toujous les thread perdus qui tournent, mais maintenant on a en plus les versions copiées ?

---

Le class Thread ne démarre pas le thread tant que tu ne fais pas appel à la méthode start donc pas de problème tu peux faire appel à la méthode enumerate sans avoir peur de dupliquer tes threads...

Par contre je ne vois pas pourquoi tu veux faire gaffe a ce que font les autres programmeurs. S'il y a un thread en vie et que tu ne sais pas pourquoi alors là, comme l'a dit Bulbo, c'est un gros problème de design.
Un thread va automatiquement s'arrêter lorsqu'il sort de la méthode run(ou de celle de son runnable).
Donc ce que tu appelles zombie c'est un thread que serait bloqué sur un IO ?
genre close d'un socket, close d'un fichier ...

Si tu es bloqué sur une socket en read, il suffit qu'un autre thread fasse close sur la socket pour que ton thread soit libéré. En fait il y a toujours une solution pour faire s'arrêter proprement un thread.

Citation:

---

Le class Thread ne démarre pas le thread tant que tu ne fais pas appel à la méthode start donc pas de problème tu peux faire appel à la méthode enumerate sans avoir peur de dupliquer tes threads...

---

Du coup, le thread enumerate réinstancie chaque thread qui tourne, ce n'est même plus une copie ! J'espère que j'ai mal compris, sinon c'est une méthode dont je ne vois pas l'utilité.

Citation:

---

Donc ce que tu appelles zombie c'est un thread que serait bloqué sur un IO ?

---

Ou une boucle infinie dans le run(), auquel cas, on peut pas faire sauter d'IO.

Encore une fois, c'est théorique, mais on voit tellement tellement d'applis avec des fuites de mémoire ou des allocations dans des boucles etc qui gonflent continuellement jusqu a provoquer des outofmemory, j'ai toujours tendance à me méfier de ce que font les autres, tant que j'ai pas moi même vu le code..

Citation:

---

Envoyé par Faiche

Du coup, le thread enumerate réinstancie chaque thread qui tourne, ce n'est même plus une copie ! J'espère que j'ai mal compris, sinon c'est une méthode dont je ne vois pas l'utilité.

---

enumerate() te renvoi simplement une copie des références des threads qui tourne. Il n'y a pas de copie de thread ou quoi que ce soit dans ce sens...


a++

La classe Thread permet de définir le code a exécuter et d'accéder aux propriétés d'un tache indépendante tournant dans la VM.

Quand tu 'recrée' avec enumerate ta classe Thread, la tache qui tourne n'en est pas affectée, elle est toujours la même. Simplement tu as recupéré un objet qui te permet de monitorer l'état de la tache en question voir de tenter de l'arrêter comme une brute.

Pour revenir a ta théorie ou un codeur aurait fait n'importe quoi, je ne pense pas que ce soit une solution viable que de courir après des taches zombies dans la VM pour les killer comme on peut. Soit on corrige, soit on change de librairie externe si c'est si pourri que ça .. mais a un moment donné il faut être sérieux dans ce que l'on fait sinon on n'aura toujours un truc instable avec des performances merdiques..

Comme tu viens du C++ ça va te faire un choc mais en java on est philosophiquement opposé aux trucs crades et bidouille en tout genre ;) et surtout le langage en autorise très peu (certains diraient même deja trop)

Bulbo ;)

Citation:

---

enumerate() te renvoi simplement une copie des références des threads qui tourne. Il n'y a pas de copie de thread ou quoi que ce soit dans ce sens...

---

Citation:

---

Quand tu 'recrée' avec enumerate ta classe Thread, la tache qui tourne n'en est pas affectée, elle est toujours la même. Simplement tu as recupéré un objet qui te permet de monitorer l'état de la tache en question voir de tenter de l'arrêter comme une brute.

---

C'est deja beaucoup mieux expliqué comme ça !

Bon, du coup, enumerate c'est pas mal.

Citation:

---

Comme tu viens du C++ ça va te faire un choc mais en java on est philosophiquement opposé aux trucs crades et bidouille en tout genre et surtout le langage en autorise très peu (certains diraient même deja trop)

---

Mettre les mains dans le cambouis, c'est pas forcément crade ni bidouillé.
D'ailleurs j'ai toujours été plus repoussé par qqun qui met le code d'une classe dans l'appel d'une fonction que par qqun qui va chercher à limiter les pertes de mémoire, quitte à ce que ce soit bidouillé.

Enfin, en terme de gestion de la mémoire et compagnie, Javolution (que je viens de découvrir) me semble aller dans le bon sens.
Malheureusement, c'est inutilisable avec la lib standard et les libs externes, et par conséquent ne sert réellement qu'en embarqué.

Mais c'est pas le sujet.

C'est juste que selon moi, un langage qui nous materne question mémoire mais qui permet les zombies, je trouvais ça étrange.
Maintenant que je sais pour enumerate(), je me sens mieux, merci :p

Citation:

---

Envoyé par Faiche

Mettre les mains dans le cambouis, c'est pas forcément crade ni bidouillé.
D'ailleurs j'ai toujours été plus repoussé par qqun qui met le code d'une classe dans l'appel d'une fonction que par qqun qui va chercher à limiter les pertes de mémoire, quitte à ce que ce soit bidouillé.

---

Mettre les mains dans le camboui a la conception du truc pour peaufiner tout ça et éviter toute perte mémoire et avoir de bonnes perfs .. 100% pour

Mais courir après des threads zombis ou des objets perdus pour je ne sais quel usage, c'est de la rustine en peau de saucisse.

Mais bon tu verras que dans le monde parfait du java, tu n'as pas trop a faire ce genre de chose.. :aie:

Bon on me dit dans l'oreillette que je suis pas objectif alors .. :dehors: