Nein, der Witz ist, dass der interne ThreadPool nur für die Ausführung des Listeners verantwortlich ist.
Das Lesen der Daten geschieht irgendwo tief im OS. Das wird auch gar nicht spezifiziert. Dennoch ist es möglich dass dies dort direkt geschieht. Wie Tuxedo bereits sagte, spart man sich da Thread-Kontextwechsel, die ziemlich teuer werden können, wenn man es häufig macht.
Hier werden viele Vorteile des neuen Konzepts im Zusammenhang mit dem Grizzly Framework näher beleuchtet: Parleys.com - The Next Generation E-Learning Platform
NIO1.4 mit den Selectors verkompliziert das wirklich nur. AIO macht genau das, was man in so einem Fall immer machen sollte, es überlässt dem OS die volle Kontrolle über das Lesen/Schreiben der Daten.
Unter Linux könnte es sogar noch aus anderen Gründen schneller sein. Laut der Doc wird bei AIO unter Linux epoll genutzt und bei NIO1.4 nur poll(). Zumindest in Jdk6, soweit ich mich errinnere. epoll ist in Etwa das Linux eigene AIO Konzept. Unter Windows wird AIO mit Overlapped I0 bzw. Completions Ports implementiert.
Alles in Allem ist es wirklcih Zeit, NIO1.4 aufzugeben. Selbst wenn AIO minimal langsamer wäre, würde ich AIO ab jetzt benutzen. Die Handhabung ist einfach super einfach im Gegensatz zu NIO1.4.
Gruß,
Chris
