Discussion :

[valerie.taesch]

Bonjour,

j'utilise Tomcat 6.0.18 avec java 1.6.0_07 et je rencontre des difficultés à gérer la mémoire.
En fait au bout d'un certain temps j'obtiens un Java Heap Space.

Dans la méthode doGet() de ma Servlet, j'ai besoin de créer un Thread et d'attendre la fin de son exécution avec un monThread.join().

Code :

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

1
2
3
4
 
Thread thread = new Thread(action); // action est une classe qui implémente Runnable
thread.start();
thread.join();

Mais j'ai l'impression que bien que la méthode doGet() soit finie, il me reste encore les Threads en mémoire dans l'état "sleeping".

Quelqu'un a-t'il déjà eu ce type de problème ? et comment le corriger ?
merci

[tchize_]

si il sont en sleeping, c'est que le thread n'a pas fini mais qu'au contraire, il est en attente de quelque chose (lock, etc. donc ca sent le deadlock).

Y a-t-il un raison particulère d'invoquer le travail dans un thread séparé? En J2EE on évite de créer des threads généralement.

[valerie.taesch]

Nous essayons effectivement d'éviter d'utiliser des Threads, mais c'est un cas particulier où nous avons besoin de faire un traitement particulier dans un Thread.

Par contre, je suis sure que le thread exécute bien le monThread.join() puisque le code juste après s'exécute. Ce que je ne comprend pas c'est que le Thread reste en mémoire alors que pour moi il a terminé de travailler. Est-ce que je rate quelque chose ?

[tchize_]

il peux rester des objet Thread en mémoire, si tu en garde des références quelque part. Par contre, si join a été atteind il ne peuvent plus être des threads dans le sens "pile d'éxécution", et donc ne peuvent pas être dans un état sleeping. Et, personellement, il me semble que si c'est pour faire


t = new Thread() {....};
t.join();

autant faire directement un new Thread(){....}.run(), qui appellera le run sans détacher un nouveau thread.

Pour saovir un peux plus ce qui foire, va falloir qu'on voie le code du thread et ce qu'il fait.