Почему блокировка IO API не была проблемой в Java в первые дни? - PullRequest
1 голос
/ 07 июля 2019

Исходный API Java IO синхронный . Начиная с версии 1.4 в Java есть NIO API, который асинхронный . Как случилось, что система, которая была разработана для использования в системах с высокой нагрузкой, не заботилась о производительности и эффективности использования ресурсов?

Технически это означает, что заблокированный поток потребляет память (~ 1-2Mb) и не делает ничего полезного. Также я понимаю, почему это считается неэффективным: просто потому, что работа на самом деле выполняется не процессором, а сетевой картой или диском, и у них нет потоков. Таким образом, нет причин блокировать поток на самом деле теоретически. Однако большинство примеров чтения сокетов Java используют поток чтения, заблокированный и ожидающий входящие символы.

Так что я хотел бы получить техническое объяснение того, почему это не было проблемой в ранней Java.

PS. Актуальный вопрос для меня заключается в том, «какой сетевой и дисковый API использовать: синхронный или асинхронный?». Как Java-разработчик, я не слишком беспокоюсь об этом, но теперь у нас в команде есть разработчики C ++, и они считают синхронный ввод-вывод Java «серьезной проблемой Java».

PPS. Мне очень нравится концепция сопрограмм Kotlin как решение этой проблемы.

1 Ответ

1 голос
/ 07 июля 2019

Реализация неблокирующего ввода-вывода JVM в значительной степени зависит от его поддержки ОС, которая на заре Java была нестабильной и неоднородной. Это никогда не было «не проблема».

...