Comment Netty utilise les pools de threads?
Pouvez-vous expliquer comment Netty utilise les pools de threads pour fonctionner? Dois-je bien comprendre qu'il existe deux types de groupes de threads: le patron et le travailleur. Les boss sont utilisés pour effectuer des E/S et le travailleur est utilisé pour appeler les rappels des utilisateurs (messageReceived) pour traiter les données?
Ceci provient du document NioServerSocketChannelFactory
Un ServerSocketChannelFactory qui crée un ServerSocketChannel NIO côté serveur. Il utilise le mode d'E/S non bloquant qui a été introduit avec NIO pour servir efficacement un grand nombre de connexions simultanées.
Fonctionnement des threads
Il existe deux types de threads dans une NioServerSocketChannelFactory; l'un est le fil conducteur et l'autre est le fil ouvrier.Fils de boss
Chaque ServerSocketChannel lié a son propre thread de boss. Par exemple, si vous avez ouvert deux ports de serveur tels que 80 et 443, vous aurez deux threads de boss. Un thread de boss accepte les connexions entrantes jusqu'à ce que le port soit libéré. Une fois qu'une connexion est acceptée avec succès, le thread de boss transmet le canal accepté à l'un des threads de travail gérés par NioServerSocketChannelFactory.Fils de discussion
Un NioServerSocketChannelFactory peut avoir un ou plusieurs threads de travail. Un thread de travail effectue une lecture et une écriture non bloquantes pour un ou plusieurs canaux dans un mode non bloquant.
Dans le modèle Nio, bossThread prend soin de tous les socket bornés (socket d'écoute), workerThread prend soin de Accepted-socket (inclus IO et méthode d'événement d'appel telle que messageReceived).
Description relative à l'implémentation de Netty Nio (3.2.4.Final) NioServerSocketChannelFactory.
Le pool de threads de travail doit être en mesure de fournir au moins le nombre de threads Workers (actuellement par défaut 2 * nombre de cœurs).
Pourquoi?
Dans le cas de cette implémentation, chaque travailleur a sa propre boucle de sélecteur, cela signifie que chaque travailleur "mangera" un fil pour dormir sur le sélecteur. De plus, ce travailleur (et le thread associé) est responsable de toutes les écritures et lectures réelles (y compris les événements de déclenchement sur le pipeline, ce qui signifie que les gestionnaires sont exécutés dans ce thread de travail).
Dans le cas du patron pool de threads, en fait le pool de threads n'est pas nécessaire car l'implémentation actuelle en acquiert un seul thread. Ce thread dort sur le sélecteur de socket serveur la plupart du temps, après avoir accepté la connexion, cette connexion est enregistrée auprès d'un travailleur. À partir de ce moment, le travailleur est responsable de servir cette connexion.