Abstract: Comprensione di BIO e NIO
Recentemente, probabilmente ho guardato il codice sorgente di ZooKeeper e Mina e ho scoperto che entrambi sono implementati in Java NIO, quindi è necessario capire cos'è NIO. Quanto segue è un mio riassunto basato su informazioni online; per risparmiare tempo, ho disegnato il diagramma con noncuranza, purché riesca a ottenere il significato.
Introduzione:
BIO: Blocco sincrono di IO, la modalità di implementazione del server consiste nel connettere un thread alla volta, cioè quando il client ha una richiesta di connessione, il server deve avviare un thread per l'elaborazione; se questa connessione non fa nulla, questo causerà un overhead inutile al thread; ovviamente, può essere migliorato tramite il meccanismo del thread pool.
NIO: Io sincrono non bloccante, la modalità di implementazione server è una richiesta per thread, cioè la richiesta di connessione inviata dal client sarà registrata sul multiplexer, e il multiplexer avvierà un thread per l'elaborazione quando la connessione avrà una richiesta I/O.
AIO (NIO.2): Io asincrono non bloccante, la modalità di implementazione server consiste effettivamente nel richiedere un thread, e le richieste di I/O del client vengono completate prima dal sistema operativo e poi notificano all'applicazione server di avviare il thread per l'elaborazione.
BIO
Blocco sincrono IO, credo che chiunque abbia imparato la programmazione di rete del sistema operativo o qualsiasi linguaggio sia familiare, nel ciclo while il server chiamerà il metodo di accettazione per attendere la richiesta di connessione del client ricevente; una volta ricevuta una richiesta di connessione, su questo socket può essere stabilito un socket di comunicazione per operazioni di lettura e scrittura, a questo punto non può più ricevere altre richieste di connessione client, può solo attendere l'esecuzione dell'operazione con il client attualmente connesso.
Se BIO vuole poter elaborare più richieste client contemporaneamente, deve utilizzare il multithreading, cioè ogni volta che accetta blocchi aspettare una richiesta client, una volta ricevuta una richiesta di connessione, viene stabilito un socket di comunicazione e aperto un nuovo thread per elaborare la richiesta di lettura e scrittura dati di questo socket, e poi continuare immediatamente ad accettare e attendere altre richieste di connessione client, cioè viene creato un thread per ogni richiesta di connessione client da elaborare singolarmente, lo schema è probabilmente questo:
C:/Users/kevin/AppData/Local/YNote/data/kevinsir2003@163.com/8107c3f773ad4d2aa1a5a476e650ef84/094528_zqyy.jpeg
Sebbene il server abbia un'alta concorrenza in questo momento, cioè può gestire più richieste client contemporaneamente, questo crea un problema: man mano che aumenta il numero di thread aperti, consuma troppe risorse di memoria, causando rallentamenti o addirittura crash del server, e NIO può risolvere questo problema fino a un certo punto.
NIO
La chiave per un IO sincrono non bloccante è adottare un'idea guidata dagli eventi per implementare un multiplexer.
La differenza più grande tra NIO e BIO è che basta aprire un thread per gestire eventi IO da più client.
È un multiplexer che può ascoltare eventi di IO da più clienti:
A. Se il server ascolta la richiesta di connessione del client, stabilirà un socket di comunicazione per essa (canale in Java), per poi tornare a continuare l'ascolto.
B. Se il server ascolta i dati inviati dal client che ha creato un socket di comunicazione, chiamerà l'interfaccia corrispondente per elaborare i dati ricevuti e, se ci sono più client contemporaneamente, anche i dati possono essere elaborati a turno.
C. Ascoltare le richieste di connessione di più client e ricevere richieste di dati, e anche ascoltare quando hai dati da inviare.
C:/Users/kevin/AppData/Local/YNote/data/kevinsir2003@163.com/41709898aa0a4f8a830d7c348ed05fbb/094528_of9c.jpeg
In breve, in un thread puoi chiamare l'interfaccia multiplexing (seleziona in Java) per bloccare e ascoltare le richieste IO da più client contemporaneamente, e una volta ricevuta una richiesta IO, verrà chiamata la funzione corrispondente per elaborarla.
rispettivi scenari applicativi
A questo punto, potresti aver notato che una volta arrivata una richiesta (che siano più volte contemporaneamente o solo una), verrà chiamata la corrispondente funzione di elaborazione IO per gestirla, quindi:
(1) NIO è adatto per gestire scenari con un gran numero di connessioni, ma le connessioni sono relativamente brevi (funzionamento leggero), come Jetty, Mina, ZooKeeper, ecc., tutti implementati basandosi su Java Nio.
(2) Il metodo BIO è adatto a scenari in cui il numero di connessioni è relativamente piccolo e fisso, richiedendo elevate risorse server ed essendo limitato alle applicazioni.
|
Pubblicato su 17/05/2019 15:34:50
|
|
|
Impara a imparare