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

Примеры запускались на доступной сегодня 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() при использовании виртуальных потоков внутри.

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

АПД: Следующий тест производительности добавлен по просьбе из комментариев. Спасибо комментатору, который напомнил мне что никогда нельзя доверять мысленным тестам производительности и всегда надо всё проверять на бенчмарками.

Я для этого теста буду использовать немного другие параметры экзекутора. Для максимального приближения к реальности. Допустим есть http сервер с пулом принимающим соединения в 100 потоков и выполняющий в них задачи с паузами в 100мс. У меня на машине всего 4 ядра, значит при нагрузке более 4% скорость работы теста определяется быстродейсвием кода, а не чем-то еще.

Экзекуторы:

Executors.newVirtualThreadPerTaskExecutor()
Executors.newCachedThreadPool()
Executors.newFixedThreadPool(100))

Тест:

@Benchmark
public void testCachedExecutorNormalTask() {
    try(var executor = Executors.newCachedThreadPool()){
        for (int i = 0; i < 100; ++i) {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            executor.submit(() -> Blackhole.consumeCPU(10_000_000));
        }
    }
}

Результаты:

100мс ожидания + 20мс работы. Нагрузка пула около 15%, 
что очень блико к реальной продакшен нагрузке хорошо сконфигуренного сервера.
Benchmark                                         Mode  Cnt       Score   Error  Units
BenchmarkThreading.testCachedExecutorNormalTask   avgt    2  677262,310          us/op
BenchmarkThreading.testFixedExecutorNormalTask    avgt    2  659306,103          us/op
BenchmarkThreading.testVirtualExecutorNormalTask  avgt    2  679307,987          us/op	

100мс ожидания + 2мс работы. Тут скорость уже перестала зависеть от скорости работы кода.
Benchmark                                         Mode  Cnt       Score   Error  Units
BenchmarkThreading.testCachedExecutorNormalTask   avgt    2  196600,036          us/op
BenchmarkThreading.testFixedExecutorNormalTask    avgt    2  191974,914          us/op
BenchmarkThreading.testVirtualExecutorNormalTask  avgt    2  196900,749          us/op

Результаты показывают что при типичной нагрузке на типичный пул http сервера виртуальные потоки не дают никакого заметного ускорения. Если цифры как следует выкрутить в сторону уменьшения аналогично предыдущим тестам мы получим ускорение. Но положа руку на сердце у кого из вас АПИшка работает на порядки быстрее чем в этом тесте?

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

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

Исследовать расход памяти в Джаве на что-то это довольно неоднозначный процесс. Предлагаю тривиально оценить расход памяти на какое-то число созданных, запущенных и ничего не делающих потоков. Это довольно типовая ситуация когда основная часть потоков висит на 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 обретает смысл.

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