Avantages de Java NIO en mode blocage par rapport aux e/s traditionnelles?
j'ai à peu près déjà décidé de ne pas utiliser le Java NIO asynchrone et non-bloquant. La complexité par rapport aux avantages est très discutable en général, et je pense que cela n'en vaut pas la peine dans ce projet en particulier.
mais la plupart de ce que j'ai lu sur NIO, et des comparaisons avec java plus ancien.io.* l'accent est mis sur les E/S synchrones, asynchrones et non bloquantes, en utilisant java.io.*. Cependant, NIO peut être utilisé en mode synchrone, de blocage, thread-per-connection, qui est rarement l'objet de discussions, il me semble.
Voici la question: y a-t-il un avantage de performance de synchrone, bloquant NIO par rapport au synchrone traditionnel, bloquant I/O (java.io.*)? Les deux seraient thread-per-connection. Comment la complexité de comparer?
notez qu'il s'agit d'une question générale, mais pour le moment je m'occupe principalement de la communication des sockets TCP.
3 réponses
un avantage de L'IO par rapport à L'IO" traditionnel " est que L'IO peut utiliser tampons directs qui permettent au système D'exploitation d'utiliser DMA pour certaines opérations (par exemple la lecture d'une connexion réseau directement dans un fichier mappé en mémoire) et d'éviter ainsi de copier des données vers des tampons intermédiaires.
si vous déplacez de grandes quantités de données dans un scénario où cette technique évite les opérations de copie qui seraient autrement effectuées, cela peut avoir un grand impact sur la performance.
cela diminue le nombre de connexions simultanées et le niveau d'occupation de ces connexions. Le blocage (thread standard par connexion) est plus rapide, tant en temps de latence qu'en débit (environ deux fois plus rapide pour un simple serveur echo). Ainsi, si votre système peut gérer le maintien d'un thread pour chaque connexion (<1000 connexions en règle générale), optez pour l'approche de blocage. Si vous avez beaucoup de connexions la plupart du temps inactives (par exemple Comet long poll requests ou IMAP idle connections) alors commutation à une architecture non bloquante pourrait aider à l'échelle de votre système.
Je ne peux pas parler de la technologie en particulier, mais il n'est pas inhabituel que des bibliothèques asynchrones fournissent des opérations synchrones pour faciliter le débogage.
par exemple, si vous avez des problèmes, vous pouvez éliminer les parties asynchrones de la logique sans réécrire tout votre processus. Cela est d'autant plus utile que les processus synchrones sont généralement beaucoup plus faciles à utiliser.