Résumé : Compréhension de la BIO et de la NIO
Récemment, j’ai probablement regardé le code source de ZooKeeper et Mina et j’ai découvert qu’ils sont tous deux implémentés en Java NIO, donc il est nécessaire de comprendre ce qu’est NIO. Ce qui suit est mon propre résumé basé sur des informations en ligne ; pour gagner du temps, j’ai dessiné le schéma de manière décontractée, tant que je parvenais à en comprendre le sens.
Introduction:
BIO : Blocage synchrone des IO, le mode d’implémentation serveur consiste à connecter un thread à la fois, c’est-à-dire que lorsque le client a une requête de connexion, le serveur doit lancer un thread pour le traitement ; si cette connexion ne fait rien, cela entraînera une surcharge inutile sur les threads, bien sûr, cela peut être amélioré via le mécanisme de pool de threads.
NIO : En E/S synchrone non bloquante, le mode d’implémentation serveur est une requête par thread, c’est-à-dire que la requête de connexion envoyée par le client sera enregistrée sur le multiplexeur, et le multiplexeur lancera un thread pour le traitement lorsque la connexion reçoit une requête d’E/S.
AIO (NIO.2) : E/s asynchrone non bloquant, le mode d’implémentation serveur consiste à demander effectivement un thread, et les requêtes d’E/S du client sont complétées d’abord par le système d’exploitation, puis notifient l’application serveur de lancer le thread pour traitement.
BIO
Blocage synchrone des IO, je crois que tous ceux qui ont appris la programmation réseau du système d’exploitation ou tout langage sont familiers ; dans la boucle while, le serveur appelle la méthode d’acceptation pour attendre la requête de connexion du client récepteur ; une fois la requête reçue, un socket de communication peut être établi sur ce socket pour les opérations de lecture et d’écriture, mais à ce moment-là, il ne peut plus recevoir d’autres requêtes de connexion client, il ne peut qu’attendre l’exécution de l’opération avec le client actuellement connecté.
Si BIO veut pouvoir traiter plusieurs requêtes clients simultanément, il doit utiliser le multithreading, c’est-à-dire qu’à chaque acceptation de blocs, attendre une requête client ; une fois la requête reçue, un socket de communication est établi et un nouveau thread est ouvert pour traiter la requête de lecture et d’écriture de données de ce socket, puis continuer immédiatement à accepter et attendre d’autres requêtes de connexion client, c’est-à-dire qu’un thread est créé pour chaque requête client à traiter individuellement, le schéma est probablement le suivant :
C:/Users/kevin/AppData/Local/YNote/data/kevinsir2003@163.com/8107c3f773ad4d2aa1a5a476e650ef84/094528_zqyy.jpeg
Bien que le serveur ait une forte concurrence actuelle, c’est-à-dire qu’il peut gérer plusieurs requêtes clients en même temps, cela pose un problème : à mesure que le nombre de threads ouverts augmente, cela consomme trop de ressources mémoire, ce qui ralentit ou même fait planter le serveur, et NIO peut résoudre ce problème dans une certaine mesure.
NIO
La clé d’une E/S synchrone non bloquante est d’adopter une idée pilotée par événements pour implémenter un multiplexeur.
La plus grande différence entre NIO et BIO est qu’il suffit d’ouvrir un thread pour gérer les événements d’E/S provenant de plusieurs clients.
C’est un multiplexeur capable d’écouter les événements d’E/S provenant de plusieurs clients :
R. Si le serveur écoute la requête de connexion client, il établira un socket de communication pour celle-ci (canal en Java), puis reviendra pour continuer l’écoute.
B. Si le serveur écoute les données envoyées par le client qui a créé un socket de communication, il appellera l’interface correspondante pour traiter les données reçues, et s’il y a plusieurs clients simultanément, les données peuvent également être traitées à leur tour.
C. Écouter les demandes de connexion de plusieurs clients et recevoir les requêtes de données, et aussi écouter quand vous avez des données à envoyer.
C:/Users/kevin/AppData/Local/YNote/data/kevinsir2003@163.com/41709898aa0a4f8a830d7c348ed05fbb/094528_of9c.jpeg
En résumé, dans un seul thread, vous pouvez appeler l’interface de multiplexage (select en Java) pour bloquer et écouter les requêtes d’IO provenant de plusieurs clients simultanément, et une fois qu’une requête d’IO est reçue, la fonction correspondante sera appelée pour la traiter.
scénarios d’application respectifs
À ce stade, vous avez peut-être remarqué qu’une fois qu’une requête arrive (qu’elle soit plusieurs en même temps ou une seule), la fonction de traitement d’IO correspondante sera appelée pour la gérer, donc :
(1) NIO convient à la gestion de scénarios avec un grand nombre de connexions, mais les connexions sont relativement courtes (fonctionnement léger), telles que Jetty, Mina, ZooKeeper, etc., toutes implémentées basées sur Java Nio.
(2) La méthode BIO convient aux scénarios où le nombre de connexions est relativement faible et fixe, ce qui nécessite de nombreuses ressources serveur et est limité aux applications.
|
Publié sur 17/05/2019 15:34:50
|
|
|
Apprendre à apprendre