Mécanisme de multithread dans Java

Question

Lorsque nous appelons la méthode #start() du thread, il appelle la méthode #run(). Mais après l'appel de #start(), le contrôle retourne à la méthode #main() (Ou l'emplacement où le thread a été créé).

Pourquoi cela se produit-il? Pourquoi le contrôle ne passe-t-il pas à la méthode #run()?

Answer 1

C'est le point de multithreading.

Le nouveau thread commence à exécuter son code (à partir de la méthode run) et le principal continue également d'exécuter son code, de sorte que le code est exécuté en parallèle.

Answer 2

Vous ne savez pas avec certitude si elle retournera à la méthode où start() a été appelée, ou si elle ira immédiatement dans le nouveau thread. L'exécution de thread Java est difficile à prévoir. Il peut aller un peu dans le nouveau thread, puis s'arrêter et revenir au thread principal, puis terminer le nouveau thread, puis revenir au thread principal, etc. Le fait est qu'il y a maintenant deux ensembles d'instructions parallèles à être exécutée, mais puisque la JVM ne les exécute pas réellement en parallèle mais une à la fois, la JVM les exécutera dans l'ordre qu'elle détermine.

Answer 3

Tout d'abord, sachez qu'un processus est juste un programme en cours d'exécution.

Chaque processus a au moins un thread, une unité d'exécution, qui est le thread principal. Les threads sont parallèles les uns aux autres.

Lorsque vous déclenchez un nouveau thread, le thread en cours à partir duquel vous l'avez déclenché est toujours en cours d'exécution (jusqu'à ce qu'il se termine, bien sûr). Maintenant, vous avez 2 threads en parallèle. Lors du débogage dans un EDI comme Eclipse, vous suivez généralement un thread spécifique, le principal. Ainsi, votre processus d'étape dans le débogage ne suivra pas le chemin d'exécution de votre nouveau thread. Il continuera simplement avec n'importe quel code après la création d'un nouveau thread.