Resumen: Comprensión de la BIO y la NIO
Recientemente, probablemente miré el código fuente de ZooKeeper y Mina y vi que ambos están implementados en Java NIO, así que es necesario averiguar qué es NIO. Lo siguiente es mi propio resumen basado en información en línea; para ahorrar tiempo, dibujé el diagrama de forma casual, siempre que pueda captar el significado.
Introducción:
BIO: Bloqueo síncrono de IO, el modo de implementación del servidor consiste en conectar un hilo a la vez, es decir, cuando el cliente tiene una solicitud de conexión, el servidor necesita iniciar un hilo para procesar; si esta conexión no hace nada, causará sobrecarga innecesaria de hilos; por supuesto, se puede mejorar mediante el mecanismo de pool de hilos.
NIO: E/s síncrona no bloqueante, el modo de implementación del servidor es una solicitud por hilo, es decir, la solicitud de conexión enviada por el cliente se registrará en el multiplexor, y el multiplexor iniciará un hilo para su procesamiento cuando la conexión tenga una solicitud de E/S.
AIO (NIO.2): E/s asíncrona no bloqueante, el modo de implementación del servidor consiste en solicitar efectivamente un hilo, y las solicitudes de E/S del cliente son completadas primero por el sistema operativo y luego notifican a la aplicación servidor que inicie el hilo para su procesamiento.
BIO
Bloqueo síncrono de IO, creo que todos los que han aprendido programación de red de sistemas operativos o cualquier lenguaje están familiarizados; en el bucle while el servidor llamará al método accept para esperar la solicitud de conexión del cliente receptor; una vez recibida una solicitud de conexión, se puede establecer un socket de comunicación en este socket para operaciones de lectura y escritura, pero en este momento ya no puede recibir otras solicitudes de conexión del cliente, solo puede esperar la ejecución de la operación con el cliente conectado actualmente.
Si BIO quiere poder procesar múltiples solicitudes de cliente al mismo tiempo, debe usar multihilo, es decir, cada vez que aceptar bloques espera una solicitud de cliente, una vez recibida una solicitud de conexión, se establece un socket de comunicación y se abre un nuevo hilo para procesar la solicitud de lectura y escritura de datos de este socket, y luego continuar inmediatamente aceptando y esperando otras solicitudes de conexión client, es decir, se crea un hilo para cada solicitud de conexión de cliente que se procese individualmente, el esquema probablemente sea así:
C:/Users/kevin/AppData/Local/YNote/data/kevinsir2003@163.com/8107c3f773ad4d2aa1a5a476e650ef84/094528_zqyy.jpeg
Aunque el servidor tiene una alta concurrencia en este momento, es decir, puede gestionar múltiples solicitudes de cliente al mismo tiempo, esto plantea un problema: a medida que aumenta el número de hilos abiertos, consume demasiados recursos de memoria, lo que puede ralentizar o incluso bloquear el servidor, y NIO puede resolver este problema hasta cierto punto.
NIO
La clave para una E/S síncrona no bloqueante es adoptar una idea impulsada por eventos para implementar un multiplexor.
La mayor diferencia entre NIO y BIO es que solo necesitas abrir un hilo para gestionar eventos de IO de varios clientes.
Es un multiplexor que puede escuchar eventos de IO de múltiples clientes:
R. Si el servidor escucha la solicitud de conexión del cliente, establecerá un socket de comunicación para ella (canal en Java) y luego volverá para seguir escuchando.
B. Si el servidor escucha los datos enviados por el cliente que ha creado un socket de comunicación, llamará a la interfaz correspondiente para procesar los datos recibidos, y si hay varios clientes al mismo tiempo, los datos también pueden procesarse sucesivamente.
C. Escucha las solicitudes de conexión de varios clientes y recibe solicitudes de datos, y también escucha cuándo tienes datos que enviar.
C:/Users/kevin/AppData/Local/YNote/data/kevinsir2003@163.com/41709898aa0a4f8a830d7c348ed05fbb/094528_of9c.jpeg
En resumen, en un hilo, puedes llamar a la interfaz de multiplexación (select en Java) para bloquear y escuchar solicitudes de IO de varios clientes al mismo tiempo, y una vez recibida una solicitud de IO, se llamará a la función correspondiente para procesarla.
Escenarios de aplicación respectivos
A estas alturas, puede que hayas notado que una vez que llega una solicitud (ya sean varias a la vez o solo una), se llamará a la función de procesamiento de IO correspondiente para gestionarla, por lo que:
(1) NIO es adecuado para manejar escenarios con un gran número de conexiones, pero las conexiones son relativamente cortas (operación ligera), como Jetty, Mina, ZooKeeper, etc., que están todas implementadas basadas en Java Nio.
(2) El método BIO es adecuado para escenarios donde el número de conexiones es relativamente pequeño y fijo, lo que requiere altos recursos del servidor y está limitado a aplicaciones.
|
Publicado en 17/5/2019 15:34:50
|
|
|
Aprende a aprender