Разница между Reactor Flux и Java Fiber - PullRequest
1 голос
/ 14 марта 2020

Я читал о Java Волокнах как небольшой единице работы, которая была бы привязана к потокам. В случае блокирующего вызова другое волокно будет сопоставлено с тем же потоком. Поскольку потоки в Java являются потоками уровня ядра, это предотвратит исчерпание потоков.

Я использовал Spring Web-Flux, поэтому просто хотел понять, что происходит внутри, когда сервер Netty получает 100 запросов / se c каждый из которых включает доступ к реактивным базам данных. Как эти запросы сопоставляются с 40 потоками, которые Netty-сервер порождает по умолчанию?

Чем поток отличается от оптоволокна? Как поток гарантирует асинхронное поведение с ограниченным числом потоков?

1 Ответ

2 голосов
/ 15 марта 2020

Что все происходит внутри, когда сервер Netty получает 100 запросов / сек c, каждый из которых включает доступ к реактивным базам данных. Как эти запросы сопоставляются с 40 потоками, которые сервер Netty порождает по умолчанию?

Короче говоря, он принимает эти запросы и назначает их стиль "циклического перебора" каждому доступному базовому потоку (когда эти потоки становятся доступными). То же самое происходит и со всеми другими реактивными вызовами, конечно, с оговоркой, которая зависит от конфигурации, они могут работать на других планировщиках и других пулах потоков с другим числом потоков.

Чем поток отличается от оптоволокна?

Это очень большой топи c, но обзор «высокого уровня» заключается в том, что поток (под которым я предполагаю, что вы подразумеваете «реактивный» Java, а не Flux) представляет собой асинхронную модель, в которой ни один поток не может блокироваться и волокна представляют собой «зеленые» нити, предназначенные для синхронного использования, в которых используются преимущественные редактирование (среди прочих методов) для отображения на гораздо меньшее количество базовых потоков на уровне ядра.

На практике это означает, что вы можете использовать почти те же самые модели потоков и методы кода, которые вы используете сегодня с волокнами, но реактивное программирование будет требует от вас принятия новых парадигм.

Каким образом поток гарантирует асинхронное поведение с ограниченным числом потоков?

Проще говоря, потому что он спроектирован как асинхронный. Здесь возникает вопрос, как будто он основан на ложной предпосылке - асинхронное поведение не гарантируется или не гарантируется количеством доступных потоков, но вашей моделью (оно не может «перетекать» в синхронное поведение, если оно перегружено запросами. )

...