Сравнение виртуальных и обычных потоков в Java

Я люблю стректрейсы и понятный линейный код. И соответственно не люблю реактивщину. Все примеры будут нереактивными с последовательным понятным кодом.

Примеры запускались на доступной сегодня jdk.

openjdk version "19-loom" 2022-09-20  OpenJDK Runtime Environment (build 19-loom+6-625)  OpenJDK 64-Bit Server VM (build 19-loom+6-625, mixed mode, sharing)

Не забываем про --enable-preview флажок.

В этой jdk доступны такие методы для экспериментирования с виртуальными потоками:

/**  * Creates a virtual thread to execute a task and schedules it to execute.  *  * <p> This method is equivalent to:  * <pre>{@code Thread.ofVirtual().start(task); }</pre>  *  * @param task the object to run when the thread executes  * @return a new, and started, virtual thread  * @throws UnsupportedOperationException if preview features are not enabled  * @see <a href="#inheritance">Inheritance when creating threads</a>  * @since 19  */ @PreviewFeature(feature = PreviewFeature.Feature.VIRTUAL_THREADS) public static Thread startVirtualThread(Runnable task) { ... }

и

/**  * Creates an Executor that starts a new virtual Thread for each task.  * The number of threads created by the Executor is unbounded.  *  * <p> This method is equivalent to invoking  * {@link #newThreadPerTaskExecutor(ThreadFactory)} with a thread factory  * that creates virtual threads.  *  * @return a new executor that creates a new virtual Thread for each task  * @throws UnsupportedOperationException if preview features are not enabled  * @since 19  */ @PreviewFeature(feature = PreviewFeature.Feature.VIRTUAL_THREADS) public static ExecutorService newVirtualThreadPerTaskExecutor() { .... }

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

Общий код запуска тестов:

@BenchmarkMode(Mode.AverageTime) @Warmup(iterations = 1) @Measurement(iterations = 2) @OutputTimeUnit(TimeUnit.MICROSECONDS) @State(Scope.Benchmark) public class BenchmarkThreading {      public static void main(String[] args) throws RunnerException {         Options opt = new OptionsBuilder()                 .include(BenchmarkThreading.class.getSimpleName())                 .forks(1)                 .build();         new Runner(opt).run();     }      //тут тесты }

Производительность

Для начала проверим самое простое. Создание потоков. Убедимся что виртуальные потоки работают так как и ожидается.

@Benchmark public void testCreateVirtualThread(Blackhole blackhole) {     for (int i=0; i<100; ++i) {         int finalI = i;         Thread.startVirtualThread(() -> blackhole.consume(finalI));     } }  @Benchmark public void testCreateThread(Blackhole blackhole) {     for (int i = 0; i < 1000; ++i) {         int finalI = i;         var thread = new Thread(() -> blackhole.consume(finalI));         thread.start();     } } 

Benchmark                                   Mode  Cnt       Score   Error  Units BenchmarkThreading.testCreateThread         avgt       199158,959          us/op BenchmarkThreading.testCreateVirtualThread  avgt           53,674          us/op

Результат получился ожидаемый и не удивительный. Виртуальные потоки создаются на порядки быстрее обычных как и ожидается.

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

Попробуем экзекутором выполнить микрозадачи:

@Benchmark public void testVirtualExecutorSmallTask(Blackhole blackhole) {     try(var executor = Executors.newVirtualThreadPerTaskExecutor()){         for (int i = 0; i < 100; ++i) {             int finalI = i;             executor.submit(() -> blackhole.consume(finalI));         }     } }  @Benchmark public void testCachedExecutorSmallTask(Blackhole blackhole) throws InterruptedException {     try(var executor = Executors.newCachedThreadPool()){         for (int i = 0; i < 100; ++i) {             int finalI = i;             executor.submit(() -> blackhole.consume(finalI));         }     } }  @Benchmark public void testFixedExecutorSmallTask(Blackhole blackhole) throws InterruptedException {     try(var executor = Executors.newFixedThreadPool(20)){         for (int i = 0; i < 100; ++i) {             int finalI = i;             executor.submit(() -> blackhole.consume(finalI));         }     } }

Benchmark                                        Mode  Cnt     Score   Error  Units BenchmarkThreading.testCachedExecutorSmallTask   avgt    2  1233,639          us/op BenchmarkThreading.testFixedExecutorSmallTask    avgt    2  2156,590          us/op BenchmarkThreading.testVirtualExecutorSmallTask  avgt    2    96,231          us/op

Результат тоже хорош. За исключение того что с размером fixed пула я не угадал. Ну ладно, на практике в продакшен коде типовой мидл тоже никогда не угадает.

А что если сделать тест еще ближе к реальности? В нормальном коде в поток выносят операции занимающее какое-то значимое количество времени.

На моей тестовой машине Blackhole.consumeCPU(100_000_000) занимает около 200мс что можно принять разумным временем на задачу которую уже можно отправлять в отдельный поток.

@Benchmark public void testVirtualExecutorNormalTask(Blackhole blackhole) {     try(var executor = Executors.newVirtualThreadPerTaskExecutor()){         for (int i = 0; i < 100; ++i) {             executor.submit(() -> Blackhole.consumeCPU(100_000_000));         }     } }  @Benchmark public void testCachedExecutorNormalTask(Blackhole blackhole) throws InterruptedException {     try(var executor = Executors.newCachedThreadPool()){         for (int i = 0; i < 100; ++i) {             executor.submit(() -> Blackhole.consumeCPU(100_000_000));         }     } }  @Benchmark public void testFixedExecutorNormalTask(Blackhole blackhole) throws InterruptedException {     try(var executor = Executors.newFixedThreadPool(20)){         for (int i = 0; i < 100; ++i) {             executor.submit(() -> Blackhole.consumeCPU(100_000_000));         }     } } 

Benchmark                                         Mode  Cnt        Score   Error  Units BenchmarkThreading.testCachedExecutorNormalTask   avgt    2  5249759,575          us/op BenchmarkThreading.testFixedExecutorNormalTask    avgt    2  5247051,750          us/op BenchmarkThreading.testVirtualExecutorNormalTask  avgt    2  5246058,750          us/op

Разницы нет. Это было ожидаемо. На такой нагрузке работа с потоками занимает пренебрежимо малое время по сравнению с бизнес логикой. Не загромождая статью исходниками покажу результат для других значений Blackhole.consumeCPU(ххх)

10_000_000 или 20мс на задачу Benchmark                                         Mode  Cnt       Score   Error  Units BenchmarkThreading.testCachedExecutorNormalTask   avgt    2  553018,934          us/op BenchmarkThreading.testFixedExecutorNormalTask    avgt    2  564500,005          us/op BenchmarkThreading.testVirtualExecutorNormalTask  avgt    2  530236,755          us/op  1_000_000 или 2мс на задачу Benchmark                                         Mode  Cnt      Score   Error  Units BenchmarkThreading.testCachedExecutorNormalTask   avgt    2  65124,411          us/op BenchmarkThreading.testFixedExecutorNormalTask    avgt    2  54710,276          us/op BenchmarkThreading.testVirtualExecutorNormalTask  avgt    2  53285,513          us/op  100_000 или 0.2мс на задачу Benchmark                                         Mode  Cnt      Score   Error  Units BenchmarkThreading.testCachedExecutorNormalTask   avgt    2  14088,289          us/op BenchmarkThreading.testFixedExecutorNormalTask    avgt    2   8267,134          us/op BenchmarkThreading.testVirtualExecutorNormalTask  avgt    2   5792,022          us/op  10_000 или 0.02мс на задачу Benchmark                                         Mode  Cnt     Score   Error  Units BenchmarkThreading.testCachedExecutorNormalTask   avgt    2  2377,223          us/op BenchmarkThreading.testFixedExecutorNormalTask    avgt    2  2757,024          us/op BenchmarkThreading.testVirtualExecutorNormalTask  avgt    2   664,795          us/op

Разница становится явно видна на совсем маленьких задачах. Там где менеджмент потоков начинает занимать значимое время от всей остальной логики.

Можно сделать вывод что в типовом нормальном Джава коде плюсов по производительности от простого включения виртуальных потоков мы не заметим. Если вы у себя её заметили, то стоит покопаться по коду поискать где вы используете потоки для слишком маленьких задач.

Зато мы получаем возможность кидать в отдельный поток просто все что угодно. Разница для микрозадач колоссальна. Это откроет некоторые возможности более удобно писать код и лучше утилизировать все доступные ядра во вроде бы однопоточном коде. Может быть наконец-то появится смысл в .parallelStream() при использовании виртуальных потоков внутри.

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

А что с памятью?

Уже давно ходят слухи что потоки в Джаве очень прожорливы до памяти. Я читал версии что каждый поток стоит мегабайты памяти просто так на создание. И виртуальные потоки всех нас спасут от покупки дополнительной памяти в наши кластера.

Исследовать расход памяти в Джаве на что-то это довольно неоднозначный процесс. Предлагаю тривиально оценить расход памяти на какое-то число созданных, запущенных и ничего не делающих потоков. Это довольно типовая ситуация когда основная часть потоков висит на IO и ждет данных. Обычно именно таких потоков хочется побольше для удобства разработки.

Приложение для оценки простейшее:

public static void main(String[] args) {     for(int i=0; i<100; ++i) {         var thread = new Thread(() -> {             Blackhole.consumeCPU(1);             try {                 Thread.sleep(100_000);             } catch (InterruptedException e) {                 throw new RuntimeException(e);             }         });         thread.start();     }     System.exit(0); } 

JDK17 LTS. Тех кто еще не обновился мне уже даже не жалко. Давно пора обновиться было.

openjdk version "17.0.3" 2022-04-19  OpenJDK Runtime Environment Temurin-17.0.3+7 (build 17.0.3+7)  OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (build 17.0.3+7, mixed mode, sharing)

Никаких особых ключей запуска: -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics -Xmx4G

71  Thread (reserved=75855304, committed=4_793_800)    (thread #71) (stack: reserved=75497472, committed=4435968)    (malloc=178456 #744)    (arena=179376 #245)  1_016  Thread (reserved=1069151112, committed=65_549_192)    (thread #1016) (stack: reserved=1066401792, committed=62799872)    (malloc=1526056 #7146)    (arena=1223264 #2040)  10_018  Thread (reserved=10532726584, committed=643_856_184)    (thread #10018) (stack: reserved=10505682944, committed=616812544)    (malloc=15013392 #70316)    (arena=12030248 #20051)

Видна хорошая закономерность с расходом около 64 килобайт памяти на пустой поток.

Виртуальные потоки в этом месте память под себя не требуют, и будут занимать что-то схожее с типичным Джава объектом размером в десятки-сотни байт. Можно упрощенно считать что это 0 по сравнению с 64 килобайтами на классический поток.

Выводы

Отрицательно:

• Нас ждут увлекательные баталии в код ревью о новых практиках написания кода.

• Количество ошибок с многопоточностью заметно возрастет.

Нейтрально:

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

• Виртуальные потоки не уменьшат потребление памяти нормально сделанным приложением. 64 килобайта * 1_000 типовых потоков, это неинтересно.

Положительно:

• Виртуальные потоки дадут возможность по новому писать код. Паралелим все что не запрещено математикой.

• .parallelStream обретает смысл.

• Виртуальные потоки дадут возможность более эффективно утилизировать доступные ядра. Без выделения больших независимых кусков кода и реактивщины.