Comments 8
Так как обращение к БД или мелкому файлу — это блокирующая операция, то тупо переводим поток в sleep.
Блокирующая, если использовать блокирующие вызовы. Странно, что вы не проверили как себя ведёт non-blocking IO.
non-blocking IO подход же реализует не фреймворк многопоточки, а конкретная сущность, которая делает IO вызов, например, сетевой клиент. Соответственно, от фреймворков многопоточки ничего зависеть не будет. Я хотел именно их между собой сравнить. И, как мне показалось, на сравнение фреймворков многопоточки, блокирующий IO или нет, не должно повлиять. Поэтому взял блокирующий, так как он сильно проще визуально и нагляднее.
Или я ошибся?
Поэтому взял блокирующий, так как он сильно проще визуально и нагляднее.
Думаю, что проще, но контекст задачи был "выполнить все обратные вызовы как можно быстрее". Использование async IO изменит результаты тестов, что может повлиять на конечный выбор.
От фреймворка зависит, что он будет делать с потоком, в котором произошел блокирующий вызов — современные фреймворки способны понять, что поток простаивает, и отдать его под соседнюю задачу. Вот-вот зарелизится Project Loom, который это все завозит в джаву из коробки, а в котлине примерно тоже самое делают корутины.
Жаль что вы не добавили Executors.newVirtualThreadPerTaskExecutor в тесты. Было бы интересно сравнить
А ссылка на github есть?
Кто и в каких задачах быстрее? Coroutines, RxJava, Executor?