Comments 9
Вы не могли бы пофиксить ошибки, которые у вас в каждом втором предложении? (Кучку отправил в личку, но потом устал это делать.)
Обработки непосредственно файлов немного. Основная логика это гит. Если правильно понял. Заголовок неверен.
а вы уверены что правильно тесты провели? например что не повлиял io кэш операционной системы (памяти то у вас многие гигабайты, ос от соблазна пригрести себе не удержится)? для этого желательно запускать разные тестовые версии поочередно и несколько раз
а так да, видел тесты, что веб сервер на неблокирующих потоках показал очень хорошие результаты по сути делая реактивную модель программирования бессмысленной с точки зрения получить какую-то выгоду в производительности, и кстати работа над виртуальными потоками продолжается, возможно какие-то улучшения попали и в 22-ую джаву, а вообще в оракл переделывают io, потому что под линуксом оказывается async file chanel был реализован без какого либо реального async со стороны os и сейчас пилят реализацию на io_uring.
если будете java в докере тестировать, то попробуйте open j9, это не оракловая jv и они утверждают что она сильно меньше памяти кушает на малых хипах и быстрее доходит до своей пиковой производительности, хоть она и меньше чем у хот спота.
И да, если смотрите прогрелась ли java то есть смысл в visualvm смотреть на табину про компиляцию методов, когда активно процесс компиляции закончился, тогда vm можно считать прогретой
А почему в заголовке упор именно на виртуальные потоки? Обычные в чем-то уступают в этой задаче?
А вы пробовали вместо потока на каждый файл банально запускать задачи в thread pool?
На что способны виртуальные потоки Java в обработке файлов