Java nieblokujące i asynchroniczne IO z NIO & NIO.2 (JSR203) - implementacje reaktora/Proaktora

Question

Java nieblokujące i asynchroniczne IO z NIO & NIO.2 (JSR203) - implementacje reaktora/Proaktora

Czytam więc jedną z moich ulubionych książek o wzorcach oprogramowania (Pattern-Oriented software Architecture-Patterns for Concurrent and Networked Objects), w szczególności sekcje dotyczące asynchronicznych wzorców Io Proactor/Reactor. Widzę, jak za pomocą wybranych kanałów mogę dość łatwo zaimplementować asynchroniczny mechanizm IO W Stylu reaktora (i zrobiłem to). Ale nie widzę, jak zaimplementowałbym odpowiedni mechanizm Proactor z nieblokującymi zapisami. To jest wykorzystanie systemu operacyjnego zarządzanego nieblokujące funkcje zapisu.

Funkcjonalność obsługiwana przez wywołania specyficzne dla systemu operacyjnego, takie jak GetQueuedCompletionStatus pod win32.

Zauważyłem, że Java 7 wprowadza pewne aktualizacje do NIO z asynchronicznymi programami obsługi dopełnień (co wydaje się być w dobrym kierunku). Skoro tak mówisz... Biorąc pod uwagę brak ujednoliconej wieloplatformowej obsługi operacji asynchronicznych zarządzanych przez system operacyjny (w szczególności zapis asynchroniczny), zakładam, że jest to quassy-implementacja, która nie wykorzystuje natywnego systemu operacyjnego wsparcie.

Więc moje pytania są następujące: czy obsługa IO oparta na proactorze jest możliwa w Javie w taki sposób, że jest to korzystne dla konkretnych scenariuszy; a jeśli Java NIO obsługuje obsługę IO opartą na proactorze (w Javie 6 lub Javie 7), czy jest używana asynchroniczna obsługa IO zarządzana przez OS (tj. wywołania zwrotne z systemu operacyjnego)? Ponadto, jeśli implementacja jest czysto in-VM, korzyści z wydajności są tak małe, że korzystanie z proaktywnej obsługi zdarzeń oferuje nic więcej niż Inny (być może prostszy) sposób konstruowania współbieżnego oprogramowania do obsługi sieci.

Dla wszystkich zainteresowanych proaktywną obsługą zdarzeń poniżej znajduje się dobry artykuł, który przedstawia zalety / wady i porównanie zarówno tradycyjnych modeli thread-per-connection, jak i reaktywnych IO.

26

design-patterns java asynchronous nio asyncsocket

Author: Jonas, 2011-04-03

Source

4 answers

Sprawdziłbym, czy naprawdę trzeba się martwić blokowaniem zapisów.

Blok odczytu, w którym nie ma danych do odczytu. To może być przez większość czasu. Jednak zapis blokuje się, gdy bufory są pełne, zdarza się to bardzo rzadko i często powoduje powolne połączenie lub awarię konsumenta.

Jeśli chcesz nieblokować IO, zrób to dla odczytów, a także dla zapisów.

Uwaga: używanie blokowania IO z NIO jest zwykle prostsze i może wykonywać nieblokowanie NIO, chyba że masz 1000 połączeń, prawdopodobnie zauważysz, że dodana złożoność nie jest tego warta. (I prawdopodobnie nie jest to najlepsza opcja)

7

Author: Peter Lawrey,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-03 15:41:48

Jeden z moich ulubionych programów książki (oprogramowanie wzorcowe Architektura-wzorce dla współbieżnych i obiektów sieciowych)

W odniesieniu do tej książki jest bardzo nieaktualne i wątpliwe znaczenie w każdym dniu. Wynikało to z szaleństwa wzorców projektowych końca lat 90., kiedy to podjęto skoordynowaną próbę zredukowania całości informatyki do wzorców projektowych.

Mój obecny pogląd jest taki, że NIO jest już ramą i wzorcem projektowym.

1

Author: user207421,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-05 10:39:07

NIO dostarcza już implementację wzorca reaktywnego (selektory), oraz NIO2 dodaje implementację wzorca proaktywnego (realizacje).

Nie wymyślaj go na nowo, po prostu użyj go, ponieważ nie możesz pokonać jego wydajności-która jest tym, co każdy próbuje uniknąć blokowania we/wy jest przecież-z czystym rozwiązaniem Java, ponieważ nie masz dostępu do nieblokujących / asynchronicznych funkcji podstawowego systemu operacyjnego. Ale NIO i NIO2 wykorzystują te, co sprawia, że są szybkie.

1

Author: Eugene Beresovsky,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 10:29:26

score 22 · Accepted Answer

Jest wiele czynników zaangażowanych w ten jeden. Postaram się jak najlepiej podsumować moje ustalenia (zdając sobie sprawę z faktu, że nie ma wątpliwości co do przydatności implementacji obsługi reaktora i proaktora IO).

Czy możliwa jest obsługa IO w oparciu o proactor w Javie w taki sposób, że jest korzystne w użyciu dla konkretnych scenariusze.

Java 1.4 wprowadziła nieblokujące IO, które nie jest takie samo jak asynchroniczne IO. Java SE 7 wprowadza asynchroniczne IO z JSR203 umożliwiające implementację obsługi IO w stylu" true " proactor.

Zobacz AsyncrhonousSocketChannel, AsynchronousServerSocketChannel

I, jeśli Java NIO obsługuje proactor oparte na obsłudze IO (w Javie 6 lub Java 7) is OS managed asynchronous IO wsparcie (tj. wywołania zwrotne zakończenia z systemu operacyjnego) są wykorzystywane?

Odczyt specyfikacji JSR 203, obsługa przy użyciu nowych asynchronicznych kanały są zdecydowanie obsługiwane i donosi się, że natywne funkcje systemu operacyjnego są wykorzystywane, ale nie ustaliłem jeszcze, w jakim stopniu. Mogę się tym zająć po analizie Źródła Javy 7 (chyba, że ktoś mnie do tego pobije).

Ponadto, jeśli realizacja jest wyłącznie w-VM są Wydajność korzyści tak niewiele, że korzystanie oferty proaktywnej obsługi zdarzeń nic więcej niż inny (ewentualnie prostszy) sposób konstruowania sieć współbieżna obsługa oprogramowania.

Nie udało mi się znaleźć żadnych porównań wydajności dotyczących nowych asynchronicznych funkcji IO w Javie 7. Jestem pewien, że będą dostępne w najbliższej przyszłości.

Jak zawsze, gdy przedstawiono więcej niż jeden sposób rozwiązania problemu, na pytania, które podejście jest lepsze, prawie zawsze odpowiada się "zależy". Proaktywna obsługa zdarzeń (przy użyciu asynchronicznych programów obsługi wypełniania) jest dołączona do Java 7 i nie może istnieć bez celu. Na w niektórych aplikacjach sensowne będzie korzystanie z takiej obsługi IO. Historycznie częstym przykładem, w którym proactor ma dobrą przydatność, jest serwer HTTP, na którym często wysyłane jest wiele krótkich żądań. Aby uzyskać głębsze Wyjaśnienie , przeczytaj to (podane tylko w celu podkreślenia zalet proactor, więc staraj się przeoczyć fakt, że przykładowym kodem jest C++).

IMO wydaje się oczywiste, że w wielu okolicznościach reaktor / proactor komplikuje to, co w przeciwnym razie byłoby bardzo proste projektowanie przy użyciu bardziej tradycyjnego podejścia i w innych bardziej złożonych systemach oferują wysoki stopień uproszczenia i elastyczności.

. . .

Na marginesie Gorąco polecam przeczytanie poniższej prezentacji na temat NIO, która oferuje porównanie wydajności NIO i "tradycyjnego" podejścia. Chociaż radzę również zachować ostrożność w odniesieniu do wyników prezentowanych jako implementacja NIO w benchmarku została oparta na pre Java 1.4 NBIO NIO biblioteki a nie implementacja NIO dostarczona w 1.4.