www.fgks.org   »   [go: up one dir, main page]

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

На что способны виртуальные потоки Java в обработке файлов

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров6K
Всего голосов 10: ↑8 и ↓2+11
Комментарии9

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

Вы не могли бы пофиксить ошибки, которые у вас в каждом втором предложении? (Кучку отправил в личку, но потом устал это делать.)

Обработки непосредственно файлов немного. Основная логика это гит. Если правильно понял. Заголовок неверен.

а вы уверены что правильно тесты провели? например что не повлиял io кэш операционной системы (памяти то у вас многие гигабайты, ос от соблазна пригрести себе не удержится)? для этого желательно запускать разные тестовые версии поочередно и несколько раз

а так да, видел тесты, что веб сервер на неблокирующих потоках показал очень хорошие результаты по сути делая реактивную модель программирования бессмысленной с точки зрения получить какую-то выгоду в производительности, и кстати работа над виртуальными потоками продолжается, возможно какие-то улучшения попали и в 22-ую джаву, а вообще в оракл переделывают io, потому что под линуксом оказывается async file chanel был реализован без какого либо реального async со стороны os и сейчас пилят реализацию на io_uring.

если будете java в докере тестировать, то попробуйте open j9, это не оракловая jv и они утверждают что она сильно меньше памяти кушает на малых хипах и быстрее доходит до своей пиковой производительности, хоть она и меньше чем у хот спота.

И да, если смотрите прогрелась ли java то есть смысл в visualvm смотреть на табину про компиляцию методов, когда активно процесс компиляции закончился, тогда vm можно считать прогретой

А почему в заголовке упор именно на виртуальные потоки? Обычные в чем-то уступают в этой задаче?

А вы пробовали вместо потока на каждый файл банально запускать задачи в thread pool?

Нет, было интересно запустить с помощью виртуальных потоках. Но я обязательно сравню оба варианта, спасибо!

Также в JEP 444, прописано следующее:

A thread pool, like any resource pool, is intended to share expensive
resources, but virtual threads are not expensive so there is never a
need to pool them.

Думаю не лучший вариант их объединять

А никто не говорит про объединение. Старые добрые потоки в пуле

В свободное время сравню оба варианта, спасибо!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории