Aller au menu - Aller au contenu

Icône Bien fermer ses threads en Java

Avatar
Par Avatar Dalshim
Mise à jour : 23/06/2009
Difficulté : Facile Facile
272 visites depuis 7 jours, classé 361/786
Avant de commencer, je considère que si vous lisez ce tutoriel, vous avez déjà des bases en Java et que vous savez ce qu'est un thread. Si tel n'est pas le cas, vous pouvez toujours aller lire le tutoriel de cysboy, en particulier la partie sur les threads.

Sur ce, bonjour à tous.

Dans cet article, nous allons traiter de la fermeture des threads. Si vous avez déjà programmé avec des threads, vous avez probablement été confrontés au problème de leur arrêt.

Certains, peu scrupuleux, auront tout simplement utilisé la méthode Thread.stop (pourtant dépréciée), tandis que d'autres auront fait des recherches pour essayer de les fermer de la façon la plus propre possible.

Nous allons donc voir pourquoi il ne faut pas utiliser cette fameuse méthode Thread.stop , et ce qu'il faut faire à la place.
Retour en haut
Sommaire du tutoriel :
Icône du chapitre
Retour en haut

Mais pourquoi la méthode Thread.stop est-elle dépréciée ?

Tout d'abord, il faut déjà comprendre ce que veut dire déprécié. Si nous passons rapidement par le dictionnaire du CNRTL, nous trouvons la définition suivante :
Citation : CNRTL
  • faire baisser la valeur de (quelque chose), diminuer sa valeur ;
  • rabaisser la valeur de (quelque chose), porter des jugements défavorables sur ;
  • Rabaisser (la valeur ou le mérite de) ; porter ou exprimer un jugement défavorable sur.

Ce que nous retiendrons pour notre usage informatique, est qu'une méthode dépréciée est à éviter. Si elle est dépréciée, c'est qu'il existe une alternative pour faire la même chose ou mieux.

Maintenant, passons aux raisons de la dépréciation. Ce n'est pas parce que la méthode est moins optimisée qu'une autre, mais bien parce qu'elle est dangereuse d'utilisation et induit des comportements aléatoires.

Pour expliciter cela, regardons rapidement la documentation :
Citation : Javadoc
Deprecated. This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception propagating up the stack). If any of the objects previously protected by these monitors were in an inconsistent state, the damaged objects become visible to other threads, potentially resulting in arbitrary behavior. Many uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. If the target thread waits for long periods (on a condition variable, for example), the interrupt method should be used to interrupt the wait. For more information, see Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?.


En résumé, cette méthode n'est pas sûre. L'utiliser pour arrêter un thread provoque le déverrouillage de toutes les ressources utilisées par le dit thread. Si une de ces ressources n'était pas dans un état stable, elle va être rendue accessible dans son état instable, ayant pour effet un comportement incontrôlable et aléatoire lors de l'usage de la ressource par d'autres threads. La documentation explique ensuite une méthode simple et générique d'arrêt « propre » de vos threads, et vous renvoie vers un lien si vous voulez en savoir plus sur le pourquoi du comment.

Pour mieux comprendre le problème, rien ne vaut un exemple.

Imaginons deux threads qui accèdent à un objet « Personne », l'un pour écrire, l'autre pour lire.
Le code est bien fait, les deux threads ne peuvent accéder à l'objet en même temps. Maintenant, imaginons que l'objet « Personne » réponde à un instant « t » aux valeurs suivantes : {Prénom = Sophie, Nom = Dupond, âge = 23 ans, taille = 170 cm, salaire = 32000 ? / an}. Le premier thread va pour le modifier en {Jean, Durant, 2 ans, 65 cm, 0 ? / an}. Il commence sa besogne, mais au milieu de son travail, il se fait arrêter (par Thread.stop ). Il se ferme et le verrou se libère. Or, il se trouve que le deuxième thread était justement en attente de la libération de ce verrou pour lire l'objet. Il va donc pour effectuer sa lecture, mais lit {Jean, Durant, 3 ans, 170 cm, 32000 ? / an} parce que le premier thread n'a pas eu le temps de finir son écriture avant d'être fermé. Les valeurs que le deuxième thread récupère sont erronées et surtout inexploitables ! Elles ne correspondent à personne. Il va donc travailler avec de « mauvaises » valeurs, produisant bien entendu un résultat incohérent.

On ne peut prédire ce que le premier thread aura modifié dans l'objet lors de son arrêt. C'est en ce sens que le comportement du reste du programme va devenir aléatoire. On n'a aucune idée de l'état dans lequel seront les données.

Je vous ai fait un exemple avec un objet « Personne » pour faire simple, mais vous pouvez remplacer cet objet par n'importe quelle autre action ou ressource ; vous comprendrez alors que les conséquences d'un code approximatif, dont on ne contrôle pas parfaitement la portée, peuvent être désastreuses.
Retour en haut

Une alternative, la boucle conditionnelle

Maintenant que nous savons comment il ne faut pas faire, voyons comment il faut faire.
Cette première solution que je vais vous présenter suffit dans une grande partie des cas. Elle est simple à mettre en œuvre et ne nécessite que très peu de code.

Prenons pour l'exemple un thread standard codé pour être arrêté avec Thread.stop :
Code : Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
class MonThread extends Thread {
    public Monthread () {
        // Mon constructeur
    }

    @Override
    public void run() {
        // Initialisation
        while(true) { // Boucle infinie pour effectuer des traitements.
            // Traitement à faire
        }
    }
}

Il suffit juste de changer et de mettre une condition dans la boucle while(running) avec running un booléen, et le tour est joué.

Pour changer la valeur de running, deux possibilités :
  • mettre une condition dans la boucle infinie ;
  • écrire une méthode.

Nous obtenons finalement le code suivant :
Code : Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
class MonThread extends Thread {
    protected volatile boolean running = true;
    public Monthread () {
        // Mon constructeur
    }

    public arret() { // Méthode 2
        running = false;
    }

    @Override
    public void run() {
        // Initialisation
        while(running) { // Boucle infinie pour effectuer des traitements.
            // Traitement à faire
            if (/*Condition d'arret*/) // Méthode 1
                running = false;
        }
    }
}
Retour en haut

Pour un code bloquant, l'utilisation des interruptions

Comme on peut vite s'en rendre compte, l'utilisation du code précédent ne fonctionne que si le thread boucle régulièrement (puisqu'il ne remarquera la demande d'arrêt qu'au commencement de la boucle). Imaginons maintenant que le thread fasse de longues attentes (comme un Thread.sleep de 5 minutes, un wait , un Thread.join ou autre), il faudrait alors attendre que l'attente de ce dernier se termine avant qu'il ne se ferme. Cette option n'est bien entendu pas envisageable, c'est pourquoi il existe un mécanisme d'interruption des threads lorsqu'ils sont en attente. Ce mécanisme répond à l'appel de la méthode Thread.interrupt.

Passons à la pratique, car son utilisation est quelque peu délicate. Prenons pour exemple le code suivant :
Code : Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class MonThread extends Thread {

    @Override
    public void run() {
        while(true) {
            // Traitement
            try {
                Thread.sleep(100000); // Pause de 100 secondes
            } catch (InterruptedException ex) {
                Thread.currentThread().interrupt(); // Très important de réinterrompre
                break; // Sortie de la boucle infinie
            }
        }
    }

    public static void main(String[] args)
            throws InterruptedException {
        Thread t = new MonThread();
        t.start();
        Thread.sleep(1000); // Attente 1 seconde avant d'interrompre
        t.interrupt();
    }
}


Lorsque le main appelle t.interrupt();, cela interrompt l'attente du thread « t » et lève l'exception InterruptedException. Il faut donc faire un catch de cette exception et la traiter comme la condition de sortie de boucle (c'est pour ça que l'on fait un break;).
Même si le thread n'est pas en attente sur le code bloquant au moment de l'interruption, celui-ci va continuer jusqu'à y arriver. Lorsqu'il arrivera au code bloquant, il lèvera alors l'exception.

Le seul morceau de code qu'il reste à expliquer est maintenant la ligne Thread.currentThread().interrupt();.
Mais pourquoi faut-il que le thread s'interrompe lui-même ?

Encore une fois, prenons un exemple :
Code : Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
public class MonThread extends Thread {
    private static boolean correct = true;

    @Override
    public void run() {
        while (true) {
            // Traitement 1
            for (int i = 0; i < 10; i++) { // Boucle imbriquée
                // Traitement 2
                try {
                    Thread.sleep(100);
                } catch (InterruptedException ex) {
                    if (correct)
                        Thread.currentThread().interrupt(); // réinterruption sur soi-même
                    System.out.println("premier Catch");
                    break; // Sortir de la boucle <italique>for</italique>
                }
            }
            try {
                // Traitement 3
                System.out.print("Devant le sleep, ");
                Thread.sleep(1000);
                System.out.print("Derrière le sleep, ");
            } catch (InterruptedException ex) {
                if (correct)
                    Thread.currentThread().interrupt();
                System.out.println("Deuxième catch");
                break; // Sortir de la boucle <italique>while</italique>
            }
        }
        System.out.println("Fermeture du Thread");
    }

    private static void test() throws InterruptedException {
        Thread t = new MonThread();
        t.start();
        Thread.sleep(2500);
        t.interrupt();
        t.join(); // Attente de la fermeture du <italique>thread</italique> avant de continuer.
        System.out.println("Fin du Thread"); // Le <italique>thread</italique> a été fermé.
    }

    public static void main(String[] args)
            throws InterruptedException {
        test();
        correct = false; // Désactive la réinterruption du <italique>thread</italique> sur lui-même.
        test();
    }
}

Si vous exécutez ce code, vous verrez qu'il ne s'arrête jamais (il ne sort pas de la boucle infinie), et on obtient la sortie suivante :
Citation : Résultat
Devant le sleep, Derrière le sleep, Premier catch
Devant le sleep, Deuxième catch
Fermeture du Thread
Fin du Thread
Devant le sleep, Derrière le sleep, Premier catch
Devant le sleep, Derrière le sleep, Devant le sleep, Derrière le sleep, Devant le sleep, Derrière le sleep, ...

On constate que si l'on relance l'interruption, celle-ci est détectée par le sleep de la boucle infinie englobante, qui donc passe dans le catch pour fermer le thread proprement. En revanche, si l'interruption n'est pas relancée, elle n'atteint pas le sleep la boucle englobante qui donc continue son exécution normalement.
On notera bien que lors de la relance de l'interruption, le « Traitement 3 » est tout de même exécuté. Ce n'est que lors du Thread.sleep que l'exception est catchée. Ce « Traitement 3 » permet justement d'éventuel changement pour l'intégrité des données avant la fermeture définitive du thread. Si vous ne voulez pas passer par ce traitement, un simple return; suffit.
Retour en haut

L'exception des InputStream

Bien sûr, tout ne pouvait être si beau et si simple, il fallait que ça ne fonctionne pas quelque part. C'est sur les lectures de flux que nous allons avoir un problème. Si votre thread est bloqué sur une ES, l'interruption ne fonctionnera pas. Java a prévu, pour pallier ce problème, une autre exception : InterruptedIOException qui hérite de IOException . Malheureusement, cette exception n'est pas encore bien gérée et ne fonctionne pas sur toutes les ES.
Ma source sur la mauvaise gestion des InterruptedIOException date un peu, mais je n'ai pas trouvé d'informations plus récentes. Si quelqu'un a d'autres informations sur le sujet, qu'il n'hésite pas à m'envoyer un MP.

Le meilleur (seul) moyen pour sortir de cette attente devient donc la fermeture du flux bloquant (j'admets que ce n'est pas génial). Heureusement, la méthode Thread.interrupt n'est pas final , il est donc possible de surcharger la méthode pour fermer le flux dans l'interruption.

Voici un code en exemple :
Code : Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
import java.io.IOException;
import java.io.InputStream;
import java.io.InterruptedIOException;
import java.io.PipedInputStream;
import java.io.PipedOutputStream;
import java.net.ServerSocket;
import java.net.Socket;

public class MonThread extends Thread {
    private InputStream in;

    public MonThread(InputStream in) {
        this.in = in;
    }

    @Override
    public void interrupt() {
        super.interrupt();
        try {
            in.close(); // Fermeture du flux si l'interruption n'a pas fonctionné.
        } catch (IOException e) {}
    }

    @Override
    public void run() {
        try {
            System.out.println("Avant la lecture");
            in.read();
            System.out.println("Après la lecture");
        } catch (InterruptedIOException e) { // Si l'interruption a été gérée correctement.
            Thread.currentThread().interrupt();
            System.out.println("Interrompu via InterruptedIOException");
        } catch (IOException e) {
            if (!isInterrupted()) { // Si l'exception ne vient pas d'une interruption.
                e.printStackTrace();
            } else { // <italique>Thread</italique> interrompu mais <italique>InterruptedIOException</italique> n'était pas gérée pour ce type de flux.
                System.out.println("Interrompu");
            }
        }
    }

    public static void test1() // Test avec un socket
            throws IOException, InterruptedException {
        ServerSocket ss = new ServerSocket(4444); // Pour accepter la connexion <italique>socket</italique>.
        Socket socket = new Socket("localhost", 4444);
        Thread t = new MonThread(socket.getInputStream());
        t.start();
        Thread.sleep(1000);
        t.interrupt();
        t.join();
    }

    public static void test2() // Test avec un <italique>PipedOutputStream</italique>
            throws IOException, InterruptedException { 
        PipedInputStream in = new PipedInputStream(new PipedOutputStream());
        Thread t = new MonThread(in);
        t.start();
        Thread.sleep(1000);
        t.interrupt();
        t.join();
    }

    public static void main(String[] args) throws IOException, InterruptedException {
        test1();
        test2();
    }
}


Citation : Résultat
Avant la lecture
Interrompu
Avant la lecture
Interrompu via InterruptedIOException


Thread.isInterrupted permet de savoir si le thread a été interrompu ou non. Ainsi, même si l'exception ne s'est pas levée parce qu'il n'y a pas de code bloquant, on sait si une interruption a été appelée.


Étant donné que InterruptedIOException n'est pas gérée pour tous les flux, il faut s'assurer de la fermeture du thread avec les deux méthodes présentées. Avec les deux tests, on voit d'ailleurs que, contrairement au pipedOutputStream , les InterruptedIOException ne sont pas gérées pour les sockets.
Retour en haut
Et voilà, j'espère que vous n'aurez plus de problèmes pour arrêter vos threads maintenant. En espérant vous avoir aidés, je vous souhaite une bonne continuation dans votre apprentissage du Java.
Retour en haut

Partager

Retour en haut
5 commentaires pour "Bien fermer ses threads en Java"
Note moyenne : 4.00 / 4 (2 votes)
Pseudo Commentaire
Hors ligne Jambo2 # Posté le 06/06/2009 à 18:22:50

Bien, je suis preneur de tout ce qui est Java.
Hors ligne afisse # Posté le 07/06/2009 à 17:42:00

sauf que, ça ne marche pas !!!
Pour stopper un thread.
la valeur de running n'est jamais changée.
Et je ne comprends pas la 2ème solution (foo==bar)???
Que sont foo et bar???
Merci.
Hors ligne Dalshim # Posté le 07/06/2009 à 20:51:23
Avatar
close

Ville : Paris
Pays : France métropolitaine
Études : INSA Lyon

 Quelle partie ne fonctionne pas ?

Pour foo == bar, foo et bar sont deux variables quelconques. L'idée est que l'on vérifie la condition d'arrêt à chaque itération (passage dans la boucle). Par exemple, tu pourrais avoir :
Code : Java
1
2
String maVariable = new Scanner(System.in).next();
if(maVariable.equals("Stop"))


Je te laisse adapter le code pour le mettre proprement dans un programme.
Apprenez à utiliser SVN
Bien fermer ses threads en Java
 
Hors ligne polmiki # Posté le 16/01/2011 à 00:08:23

C'est intéressant tout ça en m'inspirant de ton code je propose des exemples pour arreter un thread, avec une boucle conditionnelle !

Code : Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public class MonThreads extends Thread {
	 protected volatile boolean running = true;
     private int compteur;
             
     //Arreter un thread proprement
	    public void arret() { // Méthode 2
	        running = false;
	    }

        public MonThreads(){
              
                compteur= 0;
        }
        
        public void run(){
        	
          while(running) {
          compteur ++;
          System.out.println(compteur);
          if (compteur > 200000){ // Méthode 1
           running = false;	
           System.out.println("ici tout s'arrete");
          }
        }  
       } 
       
        public static void main(String[] args) {
            
        	MonThreads t = new MonThreads();
            t.start();
           
    }

}



et maintenant en implementant l'interface runnable

Code : Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class ThreadRun {
	private Thread t;
	private int compteur;
	protected volatile boolean running = true;
	
	public static void main(String[] args) {
		ThreadRun thread = new ThreadRun();
	}	
	
	public ThreadRun(){
		compteur = 0;
	    t = new Thread(new Test());
		t.start();
	}
	
	
public class Test implements Runnable{
		public void run() { 
			 while(running) {
			 compteur ++;
	          System.out.println(compteur);
	          if (compteur > 200000){ 
		           running = false;
		           System.out.println("ici tout s'arrete");
		          }
			 }
		}
	}

}


voila, voila! vous pouvez faire des tests ça marche, lorsque le compteur atteint 200000 on sort du thread !
Hors ligne Grimly # Posté le 31/05/2011 à 14:14:18

Une autre façon de faire est de modifier sa façon de penser/programmer et de laisser faire l'API java.util.concurrent . Un Executor permet de lancer des tâches. Ces mêmes lancements peuvent être planifiés avec un ScheduledExecutorService. Ainsi on a plusieurs tâches qui s'éxécuterons jusqu'au moment où on décide d'arrêter le service. L'arrêt de ce dernier est lui entièrement sauf.

L'implémentation de toutes ces interfaces est accessible bien sur via la classe Executors

Bref, divisez vos énormes opérations en tâches et laisser l'API faire ce boulot pour vous.

Voir tous les commentaires
Ce tutoriel a été corrigé par les zCorrecteurs.