Je ne suis pas sûr du traitement parallèle Java
Je vais résumer ce que je ne comprends pas. Je suis désolé de le publier même si je ne suis pas sûr. S'il vous plaît dites-moi qui sait.
Thread et exécutable
Traitement parallèle en Java = programmation multithread.
Thread est une classe qui gère les threads. Démarrez le fil avec start. Puisque l'exécution s'exécute au début, héritez de Thread et remplacez l'exécution.
Runnable est une interface de la classe qui est le point d'entrée. Passez-le à Thread et lancez-le avec start. Puisqu'il s'agit d'une interface, implémentez et implémentez run.
Seule la classe Thread peut démarrer un nouveau thread. Le comportement est exécuté. L'héritage de Thread ou l'implémentation de Runnable est une question de savoir s'il faut choisir le modèle de méthode de modèle ou le modèle de stratégie, et généralement le modèle de stratégie est adopté du point de vue de la dépendance de classe.
Ce que je ne suis pas sûr, c'est que Thread implémente l'interface Runnable. Puisqu'il implémente run, il semble que ce n'est pas faux, mais c'est déroutant. Pour une utilisation normale, oubliez d'implémenter Runnable. Je ne sais pas où cela sera utile. Il semble y avoir un débat à ce sujet lors de la sortie de Java 1.0, ce qui signifie qu'il est difficile à comprendre.
référence Kishida no Hatena Thread and Runnable
Threads Java et fuites de mémoire sur la page d'accueil de Seiichi Yoshida
Cadre de l'exécuteur
Le framework Executor a été introduit dans Java 1.5 pour reprendre la tâche de contrôle de Thread car une fois utilisé, il ne peut plus être utilisé, et même s'il est généré en grande quantité, il met la pression sur les ressources. En donnant le contrôle, les programmeurs peuvent se concentrer sur la conception des tâches. «Contrôler les threads» signifie regrouper les threads selon le modèle Worker Thread afin qu'ils puissent fonctionner efficacement.
L'exécuteur implémente le modèle de commande, de sorte que le thread puisse exécuter la tâche sans en être conscient.
L'interface du service Executor ajoute des capacités de terminaison et de suivi à Executor. Les tâches peuvent être désactivées par arrêt et les tâches peuvent être suivies par la valeur de retour Future of submit.
La classe Future est une implémentation du modèle Future. Si vous voulez obtenir Future en soumettant, passez Callable en tant que tâche. Callable est utilisé un peu comme Runnable. La seule différence est de savoir si vous obtenez ou non le résultat avec Submit. Callable n'hérite pas de Runnable. Submit peut également recevoir un Runnable, mais le résultat semble changer (je ne sais pas comment cela va changer, Futuer est nul?). Si vous soumettez, vous pouvez utiliser Callable. La différence entre Callable et Runnable est déroutante. J'aimerais pouvoir retourner Future avec Runnable. Interface RunnableFuture qui est à la fois Runnable et Future je ne comprends pas.
Executor et ExecutorService ne sont généralement pas implémentés par vous-même. Obtenez des exécuteurs comme une usine. Puisqu'il existe un service d'exécution programmé, etc., j'ai vérifié API. Executors a également un convertisseur Runnable to Callable, donc je pense que Callable est un Runnable.
De plus, c'est une sensation de parler avec le nom du motif, donc c'est douloureux si vous ne connaissez pas le motif du motif.
référence Le bloc-notes pour les programmeurs qui ne travaillent pas Java Executor est pratique
Cadre ForkJoin
Un cadre qui vise une vitesse maximale en réglant le cadre Executor pour un travail qui peut être divisé récursivement en petites unités. L'algorithme WorkStealing est utilisé pour accélérer le processus. Introduit dans Java 1.7.
Work Stealing est un algorithme qui vole du travail. Répartissez finement les tâches et placez-les dans la file d'attente, et lorsque le thread de travail reçoit une tâche de la file d'attente, volez les tâches dans d'autres files d'attente si toutes les tâches de la file d'attente sont terminées.
ForkJoinPool, qui est la fonction principale du framework ForkJoin, est une classe d'implémentation d'ExecutorService et ForkJoinTask est une classe d'implémentation de Future. ForkJoinPool implémente l'algorithme WorkStealing.
ForkJoinTask est une classe abstraite mais n'hérite pas directement. S'il ne renvoie pas de résultat, il hérite de RecursiveAction, et s'il renvoie un résultat, il hérite de RecursiveTask et implémente une classe de tâches. ForkJoinPool appelle compute depuis execute ou submit, implémentez donc le processus dans compute. Le résultat est l'avenir.
Comme nous l'avons vu à plusieurs reprises, la programmation multithread vous oblige souvent à choisir entre renvoyer et ne pas renvoyer les résultats. Je n'étais pas sûr de la différence. Est-ce plus rapide de ne pas le retourner?
ParallelStream Fonction de traitement parallèle de l'API Stream qui intègre un paradigme fonctionnel. Introduit dans Java 1.8.
C'est très simple car vous pouvez générer un Stream à partir d'un ensemble tel que Collection et réaliser un traitement parallèle avec un plan parallèle. C'est facile à faire car il est possible de décrire de manière concise le traitement fonctionnel sans effets secondaires en l'implémentant à l'aide d'une interface fonctionnelle.
Le traitement qui a des effets secondaires (change l'état) dans le traitement parallèle est tabou, mais sachez que Java a également une interface de fonction qui a des effets secondaires.
Cependant, si un réglage fin est nécessaire, il semble préférable d'utiliser le framework Executor. Dans certains cas, la série est plus rapide, et ce n'est pas parce que c'est facile que vous pouvez tout mettre en parallèle. Je ne sais pas comment l'utiliser correctement car il est difficile de tracer une ligne.
référence Legend of Java Concurrency/Parallelism -Yuichi Sakuraba
Recommended Posts