Modèles IO/NIO courants en JAVA

Nos modèles IO courants incluent : le modèle IO bloquant, le modèle IO non bloquant, le modèle IO multiplexé, le modèle IO piloté par le signal, le modèle IO asynchrone ; ci-dessous, nous présenterons brièvement les modèles IO ci-dessus ;

1. Modèle IO de blocage

Le modèle IO le plus traditionnel, c'est-à-dire que le blocage se produit pendant le processus de lecture et d'écriture. données. Lorsque le thread utilisateur émet une requête IO, le noyau vérifiera si les données sont prêtes. Sinon, il attendra que les données soient prêtes, le thread utilisateur sera bloqué et le thread utilisateur remettra le processeur. Lorsque les données sont prêtes, le noyau copiera les données dans le thread utilisateur et renverra le résultat au thread utilisateur, puis le thread utilisateur libérera l'état de bloc. Un exemple typique de modèle IO bloquant est : data = socket.read(); si les données ne sont pas prêtes, elles seront toujours bloquées dans la méthode de lecture.

2. Modèle IO non bloquant

Lorsque le thread utilisateur lance une opération de lecture, il n'est pas nécessaire d'attendre, mais un résultat est obtenu immédiatement. Si le résultat est une erreur, il sait que les données ne sont pas encore prêtes et peut donc renvoyer l'opération de lecture. Une fois que les données du noyau sont prêtes et qu'une requête est à nouveau reçue du thread utilisateur, il copie immédiatement les données dans le thread utilisateur, puis revient. Ainsi, en fait, dans le modèle IO non bloquant, le thread utilisateur doit constamment demander au noyau si les données sont prêtes, ce qui signifie que les IO non bloquantes ne remettront pas le CPU, mais occuperont toujours le CPU. Un modèle d'IO non bloquant typique est généralement le suivant :

while(true){
        data = socket.read();
        if(data!= error){
        处理数据
        break;
    }
}

Cependant, il existe un problème très sérieux avec les IO non bloquantes dans la boucle while, vous devez constamment demander si les données du noyau sont prêtes, ce qui entraînera une utilisation très élevée du processeur, donc en général, les boucles while sont rarement utilisées pour lire des données.

3. Modèle IO multiplexé

Le modèle IO multiplexé est actuellement utilisé plus fréquemment.

Java NIO est en fait une E/S multiplexée. Dans le modèle IO multiplexé, il y aura un thread qui interroge en permanence l'état de plusieurs sockets. Ce n'est que lorsque le socket a réellement des événements de lecture et d'écriture que les opérations de lecture et d'écriture IO réelles sont réellement appelées.

Parce que dans le modèle IO multiplexé, un seul thread peut être utilisé pour gérer plusieurs sockets. Le système n'a pas besoin de créer de nouveaux processus ou threads, ni de maintenir ces threads et processus, et uniquement dans. les ressources d'E/S réelles ne seront utilisées qu'en cas d'événements de lecture et d'écriture de socket, ce qui réduit considérablement l'utilisation des ressources.

Dans Java NIO, selector.select() est utilisé pour demander s'il y a un événement d'arrivée dans chaque canal. S'il n'y a pas d'événement, il y sera toujours bloqué, donc cette méthode provoquera le thread utilisateur. bloquer.

Mode IO multiplexage, plusieurs sockets peuvent être gérés via un seul thread. Ce n'est que lorsque le socket a réellement des événements de lecture et d'écriture que les ressources seront occupées pour les opérations de lecture et d'écriture réelles. Par conséquent, les E/S multiplexées sont plus adaptées aux situations où le nombre de connexions est relativement important.

De plus, la raison pour laquelle les E/S multiplexées sont plus efficaces que le modèle d'E/S non bloquantes est que dans les E/S non bloquantes, l'état du socket est constamment demandé via le thread utilisateur, tandis que dans les E/S multiplexées, interrogeant le le statut de chaque socket est effectué par le noyau, et cette efficacité est bien supérieure à celle des threads utilisateur.

Cependant, il convient de noter que le modèle IO multiplexé utilise l'interrogation pour détecter si un événement est arrivé et répond aux événements arrivant un par un. Par conséquent, pour le modèle d'E/S multiplexées, une fois que le corps de la réponse à l'événement est volumineux, les événements suivants seront retardés et affecteront l'interrogation des nouveaux événements.

4. Modèle IO piloté par le signal

Dans le modèle IO piloté par le signal, lorsque le thread utilisateur lance une opération de requête IO, une fonction de signal sera enregistrée pour Le socket correspondant. Ensuite, le thread utilisateur continuera à s'exécuter. Lorsque les données du noyau sont prêtes, un signal sera envoyé au thread utilisateur. Après avoir reçu le signal, le thread utilisateur appellera les opérations de lecture et d'écriture IO dans la fonction de signal. pour effectuer l'opération de demande d'E/S réelle.

5. Modèle IO asynchrone

Le modèle IO asynchrone est le modèle IO le plus idéal dans le modèle IO asynchrone, lorsque le thread utilisateur lance une opération de lecture. immédiatement, vous pouvez commencer à faire autre chose.

D'un autre côté, du point de vue du noyau, lorsqu'il reçoit une lecture asynchrone, il reviendra immédiatement, indiquant que la demande de lecture a été lancée avec succès, donc aucun bloc ne sera généré pour le thread utilisateur.

Ensuite, le noyau attendra que la préparation des données soit terminée, puis copiera les données dans le thread utilisateur. Lorsque tout cela sera terminé, le noyau enverra un signal au thread utilisateur pour lui dire que. l'opération de lecture est terminée. En d'autres termes, le thread utilisateur n'a pas besoin de savoir comment l'ensemble de l'opération IO est réellement effectué. Il lui suffit d'abord de lancer une requête. Lorsqu'il reçoit le signal de réussite renvoyé par le noyau, cela signifie que l'opération IO est terminée. et les données peuvent être utilisées directement.

En d'autres termes, dans le modèle IO asynchrone, aucune des phases de l'opération IO ne bloquera le thread utilisateur. Les deux phases sont automatiquement complétées par le noyau, puis un signal est envoyé pour informer le thread utilisateur que le thread utilisateur est activé. l’opération est terminée. Il n'est pas nécessaire d'appeler à nouveau la fonction IO dans le thread utilisateur pour une lecture et une écriture spécifiques.

Ceci est différent du modèle basé sur le signal. Dans le modèle basé sur le signal, lorsque le thread utilisateur reçoit le signal, cela indique que les données sont prêtes, puis le thread utilisateur doit appeler la fonction IO pour exécuter le modèle. opérations de lecture et d'écriture réelles ; dans les IO asynchrones Dans le modèle, la réception d'un signal indique que l'opération IO est terminée et qu'il n'est pas nécessaire d'appeler la fonction IO dans le thread utilisateur pour effectuer des opérations de lecture et d'écriture réelles.

Notez que les E/S asynchrones nécessitent une prise en charge sous-jacente du système d'exploitation. Dans Java 7, les E/S asynchrones sont fournies.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!