Salutations, bienvenue à nouveau. Scott Stanlick ici. Dans ces leçons, nous allons jeter un œil au threading. Nous allons regarder le thread principal Java. Nous allons avoir un pic à différents cycles de vie des threads. Nous allons jeter un œil aux pools d'exécution de threads et les planificateurs de threads. Dans cette leçon particulière, nous allons commencer par jeter un œil aux threads proprement dits. C'est généralement là que vous commencerez dans une discussion sur les fils de discussion. Alors la première chose que je veux te montrer c'est ma machine sur lequel je cours. J'ai quatre processeurs, c'est donc une machine à quatre cœurs. Nous pouvons voir que j'ai 236 processus ou applications ou des ID de processus s'exécutant dans 2 906 threads. Il y a donc beaucoup, beaucoup de threads sur la machine, beaucoup plus de threads qu'il n'y a de processus et certainement plus de threads qu'il n'y a de processeurs. Et donc ces fils passent par des changements d'état. Ils sont exécutables, ils attendent, ils bloquent, ils sont expirés, ils dorment. On verra, on verra comment tout ça se déroule ici dans une minute. Alors tout d'abord, qu'est-ce qu'un fil ? Eh bien, un thread est un processus léger qui peut être exécuté indépendamment par le système d'exploitation. En fait, il peut y avoir plusieurs fils fonctionnant tous simultanément. C'est un peu comme une autoroute à plusieurs voies par rapport à une route à voie unique. Nous pouvons donc exécuter plusieurs threads simultanément ou en parallèle. Par conséquent, faire beaucoup plus de travail dans le même laps de temps. Donc, la première chose que je veux vous montrer ici est nous avons créé une classe appelée thread de téléchargement de fichier. Donc bien sûr, c'est un fil, c'est-à-dire qu'il a une méthode d'exécution. Donc, ce que ce fil va faire sera déterminé par ce qui est codé dans la méthode run. Parce que la durée de vie du fil est la durée d'exécution de la méthode run. Voilà donc notre fil. Il va simuler un téléchargement de fichier. Donc, le premier test indique que le filetage a été mal fait et voyons à quoi cela ressemble. Quand je lance ça, il devrait sortir et comprendre combien de processeurs j'ai, que nous venons de voir, j'ai quatre processeurs. Nous ne surchargeons donc pas le matériel ici, nous ne créons plus de discussions que ce que nous avons des processeurs en ce moment. J'appelle donc la méthode run sur le thread, quatre d'entre eux en fait ici. Et je peux voir que tous ces fils ont couru sur la méthode principale avec une priorité de 5. Et que cela a pris 2,2098 secondes. Eh bien, cela ne ressemble pas à du fil pour moi. On dirait que ces choses ont été empilées en file indienne. Et ils l'étaient. C'est parce que vous n'appelez pas directement la méthode run. Vous appelez la méthode de démarrage du thread. Et la méthode de démarrage engage les machines de sorte que les tâches en arrière-plan soient créées et générées. Alors faisons-le correctement et utilisons la méthode de démarrage sur le fil et voyons à quoi ressemble ce même scénario. Les processeurs disponibles sont toujours quatre, et donc je vais voir les quatre mêmes chargements de fichiers, les quatre mêmes téléchargements de fichiers à la place, mais maintenant vous pouvez voir que c'est 0,547 seconde. Et je vois aussi qu'ils n'ont pas tous couru sur la méthode principale. C'était le fil 1, le fil 2, le fil 3, le fil 0. Donc, fondamentalement, ils étaient chacun des threads indépendants, et maintenant nous pouvons voir que nous avons fait la même quantité de travail dans un quart du temps. Donc, le prochain gars que nous allons jeter un œil est comment nous pouvons nommer les threads. Comme par exemple, c'est un peu difficile pour comprendre ce qui est quoi, non ? Surtout quand vous regardez les traces de la pile et les vidages de threads et ce genre de choses. Donc, ce que je veux faire, c'est à nouveau le même scénario, mais je veux définir le nom du fil à la connaissance-ville-numéro et il utilisera simplement le "I" dans les quatre boucles ici. Nous devrions donc voir la connaissance-ville-numéro 1, numéro 2, numéro 3, numéro 4. Et encore une fois, nous commençons ces correctement. Maintenant, le système d'exploitation va arbitrairement exécuter ces threads. Et c'est parce que nous n'avons pas défini de priorité de thread. Donc ils l'exécutent tous en priorité 5. Ils ont donc chacun la même priorité. Donc, il n'y a pas nécessairement à dire quel thread s'exécutera en premier. Et comme vous pouvez le voir ici, la connaissance-ville-numéro 1 a couru en premier, 0 a couru en dernier en fait. Et si nous l'exécutons à nouveau, vous verriez un éventail de variétés là-bas. C'est imprévisible, l'ordre dans lequel ils vont courir. Sauf si vous le faites bien sûr. Si vous définissez la priorité, si vous avez un fil particulier comme disons c'est imprimer les factures des clients et le client se tient là au comptoir, vous voulez probablement le fil qui fait l'impression avoir une priorité plus élevée, pour donner une priorité d'exécution plus élevée. Et donc ce que nous faisons ici est la même idée. Nous allons exécuter ce téléchargement de fichier quatre fois, sauf que trois d'entre eux auront une priorité 9. Je fais juste un petit switcheroo ici. Si "I" est 3, alors nous allons définir la priorité sur 5. Si "je" est autre chose que 3, nous allons mettre la priorité à 9. Donc, ce que nous devrions voir, c'est que la connaissance-ville-numéro 3 s'exécute en dernier. Parce que les trois autres avaient une priorité plus élevée alors prouvons-le. Et il l'a fait. Nous pouvons donc voir la connaissance-ville-numéro 2, numéro 1, numéro 0. Ils couraient tous en priorité 9 et ils l'ont emporté sur cette connaissance-ville-numéro 3, qui fonctionnait en priorité 5 il a donc été servi en dernier. Merci d'avoir regardé.