Как стать автором
Обновить

Реактивное программирование на Java: как, зачем и стоит ли? Часть I

Блог компании Конференции Олега Бунина (Онтико) Высокая производительность *Программирование *Java *Параллельное программирование *
Всего голосов 21: ↑19 и ↓2 +17
Просмотры 16K
Комментарии 11

Комментарии 11

Прочитал про электроны, движущиеся со скоростью света, пишу коммент перед закрытием статьи.
И зачем эти физики строят ускорители, может им научиться делать транзисторы?
В том предложении вообще всё прекрасно)
Поскольку электроны бегут со скоростью света, за счет уменьшения размера, время, которое требовалось электрону, чтобы пробежать весь путь внутри процессора, уменьшалось.

Получается, что частота процессоров растёт, потому, что электронам меньше нужно бегать)
Про световую скорость электронов уже упомянули. Реально она в проводниках порядка миллиметра в секунду
Из текста может сложиться ошибочное представление о том, что Node.js появился раньше Netty и до него асинхронность в Java не применялась, но это не так.
> Сложно писать, сложно отлаживать, сложно тестировать.

Впервые вижу эти эпитеты в отношении синхронного/многопоточного кода при сравнении с асинхронным. Отлаживать его как раз одно удовольствие по сравнению с мешаниной коллбэков. Как только project Loom с его легковесными потоками (Fibers) выйдет в продакшн будет вообще прекрасно, простой понятный синхронный код без проблем с производительностью
Асинхронный код удобно очень отлаживать. Мы в компании используем Project Reactor. Пишется как обычный Stream API и если надо, можно спокойно «провалиться» в одну из его стадий.
А в многопоточном минус в том, что можно не дождаться того результата, при котором у тебя упала ошибка, потому что потоки не предсказуемы. Они в целом выполняют задачу правильно, а вот на конкретном уровне они непонятно как могут работаться с данными.

Вообще асинхронность антоним никак не многопоточности, а синхронности. Асинхронный код точно так же работает в разных потоках, и требует синхронизации при доступе к ресурсам и т д. Его преимущество в скорости, тк создать миллионы тяжелых потоков для современных задач невозможно, но достигается это преимущество ценой усложнения разработки и отладки, и это общепризнанный факт.


Как только в java завезут файберы проблема производительности решится сама собой, и синхронный внешне код будет работать под капотом как асинхронный, и файберы можно будет плодить мильонами

Асинхронный код точно так же работает в разных потоках

Не обязательно, цикл событий может работать в одном потоке.

Как только в java завезут файберы проблема производительности решится сама собой

Серебряной пули не существует. Почитайте например цикл статей "Do Looms Claims Stack Up".
Только дочитав статью, я понял, что про реактивное программирование на java здесь ничего нет, а жаль

Когда выйдет следующая часть?

Ориентировочно статья выйдет в среду, 10 марта.
Но в этой схеме нет ожидания. Сравним ее с традиционной моделью многопоточного сервера в Java.

Что за фокусы? Есть там ожидание. Там просто более простой способ вызвать обработчик при завершении(calback, promise). В Java это нужно сделать "вручную", то есть проверять статус потока и при получении его результата вызвать какой-то код.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.