Discussion :

[emie31]

Bonjour à tous,

Lorsque je lance mon programme, quelques fois (ce n'est pas systématique), il n'arrive pas au bout (je précise qu'aucune erreur n'est générée). Je l'ai lancé en Debug, sous Eclipse, et dans les cas où le programme "rame", Eclipse ouvre la classe Thread.class et s'arrête plus particulièrement sur la méthode suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
	 /**
     * This method is called by the system to give a Thread
     * a chance to clean up before it actually exits.
     */
    private void exit() {
	if (group != null) {
	    group.remove(this);
	    group = null;
	}
	/* Aggressively null object connected to Thread: see bug 4006245 */
	target = null;
    }

Savez-vous pourquoi ? Je ne vois pas.

Merci d'avance pour votre aide.

Emilie

[Thor Tillas]

J'ai jamais eu ce problème avec les thread... essaie de détruire tes objets avant de quitter le thread...

Genre vérifier qu'il n'y a pas deux thread qui se partage une référence et donc la référence reste.
Je sais pas trop si j'ai été clair et je suis pas mal influencé par C++ ces derniers temps donc peut-être que ca n'a rien a voir...

En clair et sans trop de détour :

Vérifie qu'il n'y a pas un objet qui persiste lors de ta sortie du run...

Voilà je pense pas que c'est ca... mais on sait jamais.

[spekal]

Je ne pense pas que ce soit très significatif, cela ressemble plus à un bug du débugueur.

Si ton programme utilise beaucoup de threads, avec des risques d'accés concurrents mal foutus, je ne connais pas d'autres systèmes que de s'asseoir et de réfléchir pour essayer de trouver où est-ce qu'il y a des failles. Une fois que tu as une hypothèse, essaie de la reproduire, de la tester.

Si ton programme n'utilise pas les threads, alors procède avec des System.out.println (ou log) pour trouver ce qui se passe. (mais que cela ne t'empêche pas de réfléchir, bien sûr... disons que c'est moins utile :-)

[®om]

Si ton programme utilise beaucoup de threads, avec des risques d'accés concurrents mal foutus, je ne connais pas d'autres systèmes que de s'asseoir et de réfléchir pour essayer de trouver où est-ce qu'il y a des failles. Une fois que tu as une hypothèse, essaie de la reproduire, de la tester.

Je ne connaissais pas d'autres systèmes, mais en fait il en existe (Une méthodologie de conception/développement en 7 étapes), j'ai vu ça en systèmes concurrents (dont j'ai d'ailleurs eu le partiel ce matin). En gros c'est pour faire tes moniteurs, conditions d'acceptations, variables conditions, pre-post conditions de wait/signal... (pour ne donner que des mots-clés)

[spekal]

Oui, quand je disais pas d'autre système que la réflexion, c'est réflexion par rapport aux techniques du multitâche ofcourse.

Il y a eu également plein d'études sur la question à propos de la construction du package d'accés concurrent (java.util.concurrent), études qui ont démarré quasiment dès les origines de java (voire avant), même si elles ne se sont concrétisées que plusieurs années après (comme les génériques, d'ailleurs).

Malheureusement j'ai paumé tous mes pointeurs sur le sujet (puisque grâce à java.util.concurrent il n'est plus besoin de réfléchir, maintenant ). Si jamais tu retrouves le tien...

[®om]

Si jamais tu retrouves le tien...

Je n'ai pas vraiment de lien, je l'ai en version "papier"