Was ist der Vorteil von Async Servlets?

Hier in zwei Teilen antworten:

1. Wie ist das Async-Servlet vorteilhafter als das zuvor verwendete Thread-pro-Anforderungsmodell : Dieses Modell ist längst tot, und fast alle Java-Server verwenden NIO, wodurch diese Server Hunderte von Verbindungen mit einer Handvoll Threads verarbeiten können. Man könnte dies für Ihren App - Server überprüfen , wie gut, und Sie werden angenehm überrascht sein zu sehen , dass es nicht NIO verwenden :). Die Async-Servlets haben nichts mit der einen Anforderung pro Thread zu tun.
2. Warum dann Async-Servlets : Nun, Async-Servlets ermöglichen das Abschließen der ursprünglichen Anforderung, ohne auf den Abschluss der Async-Task zu warten (was hoffentlich lange dauert). Auf diese Weise kann der Remote-Client sofort beantwortet werden, und er kann bei Bedarf andere Aufgaben ausführen. Die asynchrone Aufgabe kann später in einem der Threads vom Server verarbeitet werden. Diese Async-Vorgänge werden normalerweise in einem separaten Thread-Pool ausgeführt, der für Async-Vorgänge vorgesehen ist. Der für die Verarbeitung von Clientverbindungen vorgesehene Thread-Pool wird nicht für asynchrone Vorgänge verwendet.

Update: Weitere Details dazu, warum wir Async-Servlets benötigen, wenn wir bereits den NIO-Thread-Pool verwendet haben. Ich habe meine Notizen vor einiger Zeit über nicht blockierende E / A unter http://manish-m.com/?p=996 notiert . Sie können auch einen verwandten Beitrag unter http://manish-m.com/?p=915 anzeigen (insbesondere den Abschnitt "IO-Spielplatz" auf dieser Seite).

Der NIO-Thread-Pool dient zur Verarbeitung mehrerer Verbindungsanforderungen . Es verwendet die nicht blockierende E / A-Funktion von Kerneln, sodass eine kleine Anzahl von Threads mit vielen Verbindungen arbeiten kann.

Dieselben Threads, die Daten aus dem Netzwerkpuffer lesen, führen jedoch auch den "Benutzercode" aus (den wir in Servlets schreiben). Das Framework des Servlet-Containers für NIO übernimmt das Akzeptieren von Client-Anforderungen, kann jedoch keinen von uns geschriebenen "blockierenden Benutzercode" selbst verarbeiten. Wenn wir also eine DB-Abfrage schreiben, die beispielsweise 10 Sekunden dauert, kann das Container-Framework diese nicht asynchron selbst verarbeiten. Wir würden den ursprünglichen NIO-Thread-Pool blockieren, indem wir Blockierungscode in Servlets schreiben. Daher müssen wir explizit alles schreiben, von dem wir glauben, dass es die Anforderungsthreads des Containers als Async-Servlet in Java EE blockieren kann.

Wenn wir andere NIO-Frameworks wie Netty, MINA verwenden, müssen wir ebenfalls sicherstellen, dass der Code die NIO-Threads, die die Netzwerkverbindungen verarbeiten, nicht blockiert. Dies wird normalerweise erreicht, indem solche lang laufenden Aufgaben in einen anderen Thread-Pool verlagert werden (was der Container tut, wenn Sie ein asynchrones Servlet schreiben).