« Bonjour, Amigo ! Nous te proposons un sujet nouveau et très difficile. Pardon. Il est souvent considéré comme un des sujets les plus complexes non seulement en Java, mais aussi en programmation en général. Je parle là du multithreading. »

Imagine un jeu vidéo typique, par exemple un jeu de course de vaisseaux spatiaux. Tu voles à travers les étendues du cosmos, esquivant les météorites et les patrouilleurs galactiques. Deux dizaines d'autres concurrents participent avec toi à ces courses illégales.

Disons que tu décides d'écrire un tel jeu. Ton programme devra garder la trace des commandes (entrée du clavier), déplacer les vaisseaux spatiaux, calculer leurs trajectoires, déterminer les conséquences des collisions, et dessiner tout cela sur l'écran de l'utilisateur. C'est un travail très complexe.

Tu te souviens de comment nous avons résolu le 'problème de grande complexité' dans l'exemple de la société de livraison en pleine croissance ?

Nous l'avons divisée en services indépendants avant de spécifier (standardiser) strictement leurs interactions.

« Mais que faisons-nous lorsque les parties indépendantes doivent effectuer des travaux en parallèle avec les autres parties !? La réponse à cette question nous est apportée par les threads. »

Essaie d'imaginer un programme comme étant un petit robot qui court à travers le code et exécute les commandes. D'abord, il exécute une commande sur une ligne, puis passe à la suivante, et ainsi de suite.

« J'arrive à visualiser ça, oui. Fastoche ! »

« Très bien. Et imagine maintenant que tu as plusieurs de ces robots. Tandis qu'un gère les entrées de l'utilisateur, un deuxième met à jour les objets en fonction de ces entrées. Un troisième exécute le code pour afficher ces objets à l'écran. Plusieurs fois par seconde, un quatrième vérifie si les navires sont entrés en collision et, si c'est le cas, calcule les résultats de la collision. »

Ainsi, nous pouvons non seulement diviser le programme en parties/objets indépendants, mais aussi faire en sorte que ces parties puissent effectuer leur travail indépendamment les unes des autres. Moins il y a d'interactions entre les différentes parties, moins le programme est complexe.

Imagine que tu peux remplacer le responsable d'un service par un script qui envoie des lettres. Et les autres services de l'entreprise ne sont même pas en mesure de dire qu'il y a eu un changement. Ce genre de chose est arrivé dès le 26e siècle avec d'excellents résultats. La plupart des responsables, et même des cadres supérieurs, peuvent être remplacés avec succès par un script de complexité moyenne. Ce n'est qu'après l'intervention du « syndicat planctonique » que les licenciements massifs de responsables ont pris fin. Mais, je m'égare.

« C'est super intéressant ! »

« Non seulement il peut y avoir plusieurs de ces 'petits robots' qui exécutent du code, mais ils peuvent également communiquer entre eux et engendrer de nouveaux robots. »

« Engendrer de nouveaux robots ? »

« Oui, pour effectuer de nouvelles tâches. Parfois, il est avantageux de créer un autre robot (un autre thread) pour effectuer une action en même temps que le thread (robot) actuel. »

« Ça m'a l'air d'être une bonne chose, mais j'ai du mal à voir où je pourrais utiliser ça. »

Et pourquoi on les appelle 'threads' ?

« Imaginons que chaque robot est d'une couleur différente et qu'il marque les commandes avec sa couleur quand il les exécute. Le chemin emprunté par le petit robot est comme la ligne dessinée par un crayon. Le chemin suit le robot, comme un fil (thread, en anglais) derrière une aiguille. »

Chaque 'petit robot' a une tâche qu'il a été créé pour exécuter. Tu peux voir un thread comme l'ensemble des commandes exécutées lors de l'accomplissement de cette tâche.

Disons que tu pilotes un vaisseau spatial pour livrer des cargaisons. Dans ce cas, 'livrer la cargaison' est ta tâche, et tu es en train de l'exécuter. Et ta trajectoire de vol est ton thread. On pourrait dire que chaque nouvelle tâche, chaque tâche non encore terminée, a son propre thread (un chemin qui doit encore être parcouru).

« En d'autres termes, il y a une tâche, et un 'petit robot' qui l'exécute. Et un thread est simplement le chemin emprunté par le robot pendant qu'il effectue sa tâche ? »

« Exactement. »

C'est comme ça que ça fonctionne en coulisses. Comme l'ordinateur ne possède qu'un seul processeur, il ne peut exécuter qu'une commande à la fois. Alors voici ce qui se passe : le processeur passe en permanence d'un thread à l'autre. Il passe à un nouveau thread, exécute quelques commandes, puis passe à un autre thread, exécute quelques commandes, et ainsi de suite. Mais comme le basculement entre les threads se produit des centaines de fois par seconde, nous avons l'impression que tous les threads s'exécutent simultanément.

Multithreading - 1