Gestion des threads en Java

De nombreuses applications ont recours aux threads. Ceux-ci permettent notamment de lancer des opérations asynchrones, ou tout simplement d’éviter de bloquer la GUI. Seulement, la facilité de lancer un thread fait qu’on est tenté d’appeler directement new Thread() dès qu’on veut en lancer un. Or il s’agit d’une erreur pouvant avoir de fâcheuses conséquences sur les performances de l’application pour plusieurs raisons :

• Lancer un nouveau thread coûte très cher en terme de CPU. Rien que la commutation volontaire d’un thread vers un autre coûte 80000 cycles CPU, car il faut passer d’une pile à l’autre, vider certains registres, etc, etc.
• Si on n’y prête pas garde, le nombre de threads lancés par votre application peut dépasser le nombre de coeurs d’exécution disponible sur la machine sur laquelle l’appli est déployée. Et là c’est catastrophique car le processeur passera alors plus de temps à effectuer des commutations de threads qu’à exécuter votre code.

Dès lors, voyons quelques bonnes pratiques pour l’usage des threads.

Débloque les + belles offres tech en 10 mins

Implémentation d’une classe devant tourner dans un thread

Quand on implémente une classe devant tourner dans un thread, il est tentant d’hériter directement de java.lang.Thread. Or il s’agit là d’une erreur de design, car si votre classe a besoin d’hériter d’une autre classe, vous ne pouvez pas le faire. Le mieux est que votre classe implémente directement l’interface java.lang.Runnable, qui contient directement la méthode public void run() appelée par java.lang.Thread.

Ensuite, pour lancer le thread, il convient d’appeler la méthode start() et non la méthode run(), cette dernière n’exécutant pas de thread mais exécutant simplement le code de votre méthode run().

Trucs et astuces sur l’implémentation des threads

Si vous lisez la doc des threads, vous verrez qu’il y a quelques méthodes qu’il ne faut en aucun cas appeler :

• suspend()
• resume()
• stop()

En fait c’est tout simplement parce qu’elles ne sont pas considérées comme sûres. Dès lors voici une petite implémentation permettant d’avoir tout de même ces fonctionnalités. Comme vous pouvez le constater, tout n’est pas idéal non plus car le stop et le suspend n’ont pas d’effet immédiat. D’un autre côté on évite ainsi d’interrompre un traitement en cours brutalement, ce qui permet de ne pas avoir d’état indéfini lorsqu’on suspend l’exécution de notre thread.

public class MyRunnable implements Runnable {

   /**
    * The lock monitor, used to manage suspend/resume.
    */
   private final Object lockMonitor = new Object();

   /**
    * Flag indicating that the thread must be stopped. Note that it is volatile to ensure that all threads
    * always take the last value written into account.
    */
   private volatile boolean isStop;

   /**
    * Flag indicating that the thread must be suspended. Note that it is volatile to ensure that all threads
    * always take the last value written into account.
    */
   private volatile boolean isSuspend;

   /**
    * Constructor.
    */
   public MyRunnable() {
      this.isStop = false;
      this.isSuspend = false;
   }

   /**
    * Stop the thread.
    */
   public synchronized void stop() {
      this.isStop = true;
      lockMonitor.notifyAll();
   }

   /**
    * Suspend the thread.
    */
   public synchronized void suspend() {
      this.isSuspend = true;
   }

   /**
    * Resume the thread.
    */
   public synchronized void resume() {
      this.isSuspend = false;
      lockMonitor.notifyAll();
   }

   /**
    * {@inheritDoc}
    */
   public void run() {
      while (!this.isStop) {

         synchronized(lockMonitor) {
             while (this.isSuspend) {
               try {
                  lockMonitor.wait();
               } catch (InterruptedException e) {
                  // Log exception
               }
               if (this.isStop) {
                  return;
               }
            }
         }

         // Do your stuff
      }
   }
}

Gestion manuelle des pools de threads

Pour gérer manuellement un pool de threads, le plus simple à faire est d’avoir d’un côté votre implémentation de java.lang.Runnable qui contient un traitement, et de l’autre côté une BlockingQueue qui contient la liste des tâches à exécuter, sur laquelle on aura bien pris soin de définir une taille.

L’idée est en fait qu’un ou plusieurs threads vont produire des descripteurs de tâches, et un ou plusieurs threads vont les traiter. La blocking queue va mettre les producteurs en attente quand elle sera pleine, et les consommateurs en attente quand elle sera vide.

Le dernier truc à faire est d’ajouter à tout ce beau monde un flag permettant de savoir quand tout doit être arrêté.

J’ai mis ici un exemple de code pour la gestion manuelle d’un pool de threads.

L’ExecutorService

Le rôle de l’ExecutorService, apparu avec Java 5, est de permettre de gérer plus simplement un pool de threads. L’idée est qu’au départ on dimensionne l’ExecutorService pour un certain nombre de threads, et ensuite on lui passe des Callable our des Runnable à exécuter de manière asynchronie.

Un bon article (en anglais) présente de manière plus détaillée l’ExecutorService.

Et alors, que choisir entre une gestion manuelle des pools de threads et l’ExecutorService ?

Il est vrai que la gestion manuelle de pools de threads demande d’écrire un peu plus de code, par contre son point fort par rapport à un ExecutorService auquel on soumettrait en peu de temps un grand nombre de tâches est de permettre d’éviter de saturer la mémoire. L’ExecutorService utilise aussi une BlockingQueue de Callable et Runnable pour obtenir le même résultat, mais sans qu’on ait directement la main dessus, bref après c’est selon les goûts et les couleurs.

Débloque les + belles offres tech en 10 mins

Cet article vous a plu ? Vous aimerez sûrement aussi :

• Les toolkits graphiques et les threads
• De la nécessité d’utiliser des structures de données thread safe en environnement multithread
• Quelques principes d’architecture d’applis Web en Java/JEE

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter – Son LinkedIn